Systemd? why?

Question

i installed systemd with initscripts for arch.
i improve my boot just a little and something like rc.local.service don't work.
my question is: why systemd for a fast distribution like archlinux?

Answer 1

mrmylanman wrote:
Just to throw some additional information in here:
systemd will be officially supported soon (see http://mailman.archlinux.org/pipermail/ … 2803.html), and may even become the default.
Not sure if anyone knew that or not, but I'd say this lends more "credibility" to it, in my opinion.  I also have had nothing but pleasant experiences using it.
Yeah i read that, which was what made me wanting to vent and ask and discuss it again.
tomegun wrote:
PReP wrote:
1: - on demand activation of services (e.g. you really don't need cups running all the time)
   My take on this, is that it is better to not run too many services in the first place,
   even if you "feel" like you need this and that.
   For the few that you use very rarely, i feel it very easy to just start it myself.
   In this case, instead of "running cups all the time", one would run the system to check when to run this or that - all the time instead.
I don't really get your point here. With systemd you get all the benefit of not running any unneeded daemons, but at the same time you never have to start daemons manually when needed... Why would you rather manually start cups when you need it instead of having it start by itself only when needed?
2: - almost anything is a unit, meaning it can be a dependency (e.g. any sysfs path, device, filesystem path)
   What are the biggest benifit of this in practice, for a fine-tuned maching not running too many services?
The simpler your setup, the smaller the benefit of course. That said, the benefit would be that you can start a daemon when a certain device is plugged in (e.g. bluez when a bluetooth adapter appears or cups when a printer is connected), or when a certain file appears, etc.
This is obviously not something for everyone, but for early boot (think rc.sysinit) this kind of control is very useful, and allows us to remove some hacks that we currently have.
3: - automounting of any device on first access with fsck pre-mount (how often do you really need /boot mounted?)
   For me, all the normal drives are mounted in fstab, to be there all the time anyways,
   and others, like my usb or cd'drives, i really do prefer to mount them myself at need,
   most usb drives has a long wake-up time, so it is quite annoying to have it re-mounted when accessed,
   and it takes quite a bit of time,
Systemd is only meant to control devices in /etc/fstab, typically your usb devices would be controlled by udisks, so that is sort of a different discussion. It might be worth pointing out that systemd would not "re-mount on access", the fs is fsck'ed and mounted on first access and stays mounted after that. Examples of why this might be useful is, as Dave mentioned, fs'es that are rarely used (/boot), but also fs'es that are always mounted might benefit from automounting. In order to speed up my boot I automount my /home. This means that systemd will start fscking/mounting it as soon as it can, but it will not wait for /home to be available before starting kdm (or any other service). Rather, if and when kdm tries to access /home it will just wait until the directory becomes available.
4; - daemon supervision
   This i cannot comment, since i do not have much knowledge on the subject,
   what are supervised, besides from the previously noted dep-check, and what are the benifits?
This (along with the point below) is the most important feature of systemd, imho. The point is that with systemd an administrator can know the state of the system, which is not really possible with sysvinit. You can find out if a daemon is running, stopped or crashed, and you know which processes belong to which daemon. Even if you have several instances of the same daemon, and it's children have double-forked (so a simple "ps aux" tells you nothing). Once we have this, we can make policies of what to do in given scenarios. Restarting crashing daemons, etc. As of the next version of systemd we'll also have (optional) watchdog support. I.e., if a daemon hangs without crashing, it will be restarted, and if systemd itself hangs  the computer will be rebooted.
5: - fine grained control of services -- niceness, oom_adj_score, scheduling policy, fd 0,1,2 redirections, syslog facility/prio, security limits...
   Are these really properties that we cannot already control without systemd as a system-swiss-army-knife?
Everything can be controlled in the individual rc script now. However, especially in the case of security sensitive settings, getting it right is very difficult so it either not done, or it is done wrongly. In systemd's unit file, you just specifiy what you want, and systemd itself will take care of all the fiddly details to get it right (and if there are bugs, they will be fixed in one place that benefit all daemons, on all distros).
Finally, the boot-time discussion also feels a bit unmotivated,
again, not booting every service under the sun already,
and computer-speed increasing alleviates this.
I believe that boot-time can never be fast enough, and with systemd we have the opportunity to improve it a lot. Imagine the embedded case of switching on a phone / TV. You don't want to wait around for several seconds before you can use it. The fact that we accept long waits when it comes to computers is just sad imho.
While systemd already improves speed somewhat (or a lot, depending on who you ask), there are still lots of cases to improve, so I am very optimistic about this. The difference between systemd and sysvinit is that in sysvinit we don't have the architecture in place to start optimizing, and we don't have contributors who focus on this.
The booting time is the thing that bothers me most to be hearing about repetively as a reason for systemd, even if that might not be it's larger drive.
The boot times _are_ fast already, when one deals carefully with what one runs or loads,
shaving,. say, 1-10 to perhaps even 20 seconds for booting off (if going extreme), what would one have done in those few seconds that was so important?
For me, it feels like taking one, or three sips on my coffe or not, before getting to business,
it is not something that hinders me from completing my work, those few seconds,
and a stable system is not meant to be booted often at all.
Even booting as often as once a day, 20 seconds a day is not a critical lose of time.
I boot in about 8 seconds after bios and grub has done their thing, and my mothers much older machine does it in 15 perhaps,
it was a long time ago boot time felt annyoing in my opinion.
The other virtues you meantion, they do sound like good things, certainly,
but as it stands now, having followed the systemd mailing list, and arch-dev-mail discussions, and threads here on arch,
i still don't see any great benifits from what i read people discussing/saying/reporting.
Most often, it is about why something that has already worked well, does not work that easily, with systemd.
And in the systemd mailing list, many replies to things not working seems to end with stuff like:
"Well, we won't support that no more/that is not supported no more on fedora, other distros will probably follow suit",
Why all the fuss?, do we really need to repair things?
I will deal with systemd when i have too, i just do not think it fits into either KISS,, or linux principle,
And i hope Arch can be on systemd and still feel Arch, not just turning into "a distro like the others only with pacman".
Systemd gives me this feeling of slowly loosing the control i have gotten with linux, over,
say, windows-systems and their "services".
But, i think i will save some of my arguments until we have seen where systemd takes us, in linux,
I just hope people stay positively/constructively critical and thinks things over closely
(Oh i do find it hard explaining my thoughts on this in words)
Last edited by PReP (2012-04-15 16:46:23)