systemd? why?

mancino · 2011-09-05 10:41:30

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?

tomk · 2011-09-05 10:48:40

Why not?

Also, aren't you meant to ask why before installing it?

mancino · 2011-09-05 11:05:03

off course why not, but archlinux is fast too and more clean for me.

Teho · 2011-09-05 11:07:07

http://0pointer.de/blog/projects/why.html

It's simply the most powerful init system for Linux. Not to mention that it's easy to use and will be adopted by every major linux distribution in near future (Fedora, Mandriva and openSUSE have already done that).

yngwin · 2011-09-06 05:26:08

I see no good reason to use systemd. Especially knowing who the author is. And it seems like a load of bloat to me. It wants to do too much.

If you really want an alternative to the standard Arch init system, I'd suggest runit.

ewaller · 2011-09-06 05:44:58

Moderator comment.

yngwin, this would be a good time to review our policy on showing respect for others and unproductive slander (well, technically libel)

pogeymanz · 2011-09-06 12:42:01

There are basically three main reasons for systemd. And, frankly, you should probably become okay with the idea of systemd because it seems like it has a ton of momentum and will be standard very soon.

1) It's fast. Faster than traditional SysVinit. It starts stuff in parallel and only when needed.

2) Processes don't get lost after forking, like is possible with SysVinit. This is good for having long uptimes because you'll never have to hunt for orphaned processes.

3) It has lots and lots of features and capabilities that other options don't. You may or may not use these.

Usually, I champion Linux's modularity as a feature, but having an underlying, consistent, unified framework for controlling the system will add to stability and make life easier for sys admins, developers and users alike. It makes Linux more like a big boy OS and less like a hodge podge.

The word "bloat" is thrown around way too much. The only feasible bloat added by systemd is the dependence on dbus. If it runs faster and does a better/smarter job than the competition, then why would be complain about it's extra features as if they are a detriment?

Last edited by pogeymanz (2011-09-06 12:43:48)

jiyuu · 2011-09-06 13:44:32

pogeymanz wrote:

1) It's fast. Faster than traditional SysVinit. It starts stuff in parallel and only when needed.

Sometimes systemd is 2-3 sec faster. Sometimes it's 5-7 sec slower on my machine. Not much a progress personnaly.

pogeymanz wrote:

2) Processes don't get lost after forking,

I feel like it's the only advantage systemd has.

pogeymanz wrote:

3) It has lots and lots of features and capabilities that other options don't. You may or may not use these. [...] The word "bloat" is thrown around way too much.

hehe

pogeymanz wrote:

it has a ton of momentum and will be standard very soon.

IIRC only 3 (big) distributions is using it: Fedora, OpenSuse, Mageia.
Ubuntu has upstart, Debian hasn't move to systemd, Gentoo hasn't, Arch isn't going to switch in the near future and don't make me talk about the *BSD. So in what way systemd is going to be standard ?

I don't want to be seen as a troll. I have nothing against systemd. I have tried it but it feel like it try to solve a problem I don't have. Sure it may be helpful for some people but I just hope it will not be forced upon us archer as I don't see a valid reason to switch to it.

Awebb · 2011-09-06 14:00:04

Maybe it's time to talk about packaging and you'll see, why. As far as I understand Arch development, a package is made, when a packager is found who's willing to maintain it and if there is the relevant interest in it by the community. That's why.

I don't use it. I'm fine with rc.d and friends, but I will play around with it when I'm really bored. Maybe never. I will, however keep informed about what it can and cannot, maybe I need it one day.

Teho · 2011-09-06 14:15:23

jiyuu wrote:

IIRC only 3 (big) distributions is using it: Fedora, OpenSuse, Mageia.
Ubuntu has upstart, Debian hasn't move to systemd, Gentoo hasn't, Arch isn't going to switch in the near future and don't make me talk about the *BSD. So in what way systemd is going to be standard ?

MeeGo will adopt systemd in near future. Mandriva already has. It would be too stupid for Canonicial to invest in developement of Upstart when there is an superior alternative avaible so I'm sure they will switch after next LTS (developement isn't exactly a virtue of Canonicial anyway). I haven't heard anything about Chrome OS but as speed is their ultimate goal it's kinda obvious that they want to use systemd...

Next RHEL will switch to systemd which means that at least CentOS, Scientific Linux, Unbreakable Linux are also going to.

Only reason that I have heard for Debian no to switch to systemd is their quite ridiculous goal to have multiple kernels under single base or something. I'd suprised if they really stick to it.

falconindy · 2011-09-06 14:31:12

jiyuu wrote:

I feel like it's the only advantage systemd has.

- on demand activation of services (e.g. you really don't need cups running all the time)
- almost anything is a unit, meaning it can be a dependency (e.g. any sysfs path, device, filesystem path)
- automounting of any device on first access with fsck pre-mount (how often do you really need /boot mounted?)
- daemon supervision
- fine grained control of services -- niceness, oom_adj_score, scheduling policy, fd 0,1,2 redirections, syslog facility/prio, security limits...

While it might seem "bloaty" to some people, I say that sysvinit doesn't do nearly enough. systemd's integration with other components only serves to give you better control over long running processes. For those who like to get their hands dirty, systemd is incredibly knobby, with a lot more configuration than most other init systems. At the same time, the provided defaults are enough to get a functional system up and running without a lot of effort.

Feel free to tell me I've drunk too much of the kool-aid, but I'm just pointing out why you might be interested in trying it.

Dieter@be · 2011-09-06 15:01:09

falconindy wrote:

- almost anything is a unit, meaning it can be a dependency (e.g. any sysfs path, device, filesystem path)
- automounting of any device on first access with fsck pre-mount (how often do you really need /boot mounted?)

that's interesting.
Suppose myscript.sh does something in /home/dieter/foo/bar and that /home/dieter/foo directory is a mountpoint I rarely use.
When I execute myscript.sh, will systemd automatically mount /home/dieter/foo ? Or am I supposed to make a unitfile for myscript.sh with a dependency on /home/dieter/foo ?

falconindy · 2011-09-06 15:37:55

If you add 'noauto,comment=systemd.automount' to the options in /etc/fstab for the mount at /home/dieter/foo, it'll be fsck'd and mounted on first access. It's done via the kernel's autofs. No extra unit files needed.

PReP · 2012-04-15 00:43:46

I don't want to be all to "necro'ing", but i do not want to start another new thread when i harbour the same why.
I wonder a bit more on some of these points:

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.

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?

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,

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?

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?

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.

Both my Corei5 2500k, and my mothers old AMD Phenom x2,
boots fast enough to not make one feel like waiting for something,

DAEMONS=(ntpd syslog-ng network crond alsa)

Though i might be a caveman-user who just nags and do not see the whole picture,
I do not fancy dbus or udiskie either

Last edited by PReP (2012-04-15 00:47:25)

graysky · 2012-04-15 11:34:06

Systemd boots much faster on an ssd vs HDD in my experience. I haven't timed it vs sysv so I won't give a number but it is faster to answer the original question.

tomegun · 2012-04-15 12:40:23

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.

mrmylanman · 2012-04-15 14:32:42

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.

PReP · 2012-04-15 16:39:33

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)

tomegun · 2012-04-16 22:40:05

PReP wrote:

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.

I get why people might not think this is very important. It probably is the least important reason to want to use systemd (and I'd be advocating it even if it had been slower than what we currently have). The important points are that the architecture is well made and allows us to build more robust and correct systems.

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?

Hm, without any examples it is a bit difficult to know what to make of this. What is more difficult to make work? Is this just due to things being new, or due to architectural differences? What is not supported? Are these real world usecases? When/who has said they don't care about repairing broken things (this last I think I would have remembered)?

I have been following (and contributing to) systemd since the beginning, and I really think you are misrepresenting the systemd dev's attitude. Sure, there are bugs. However, they are (in my experience) taken seriously and fixed, even if they do not directly affect the people doing the work.

Where people have had problems with using systemd it is mostly trying to do new and fancy things with the new and fancy features. Getting things to work "just as before" should not be a problem at all (and I have not seen much of this being reported.

There are a few things that were traditionally supported, but that will not be supported natively in systemd. However, in my opinions these were all dropped for good reasons (RTC in localtime for instance), and would be trivial to get to work by making some third-party units do the work.

I hope people will try out systemd and help us make it work well on Arch, by reporting bugs and documentation issues :-)

Arch Linux

#1 2011-09-05 10:41:30

systemd? why?

#2 2011-09-05 10:48:40

Re: systemd? why?

#3 2011-09-05 11:05:03

Re: systemd? why?

#4 2011-09-05 11:07:07

Re: systemd? why?

#5 2011-09-06 05:26:08

Re: systemd? why?

#6 2011-09-06 05:44:58

Re: systemd? why?

#7 2011-09-06 12:42:01

Re: systemd? why?

#8 2011-09-06 13:44:32

Re: systemd? why?

#9 2011-09-06 14:00:04

Re: systemd? why?

#10 2011-09-06 14:15:23

Re: systemd? why?

#11 2011-09-06 14:31:12

Re: systemd? why?

#12 2011-09-06 15:01:09

Re: systemd? why?

#13 2011-09-06 15:37:55

Re: systemd? why?

#14 2012-04-15 00:43:46

Re: systemd? why?

#15 2012-04-15 11:34:06

Re: systemd? why?

#16 2012-04-15 12:40:23

Re: systemd? why?

#17 2012-04-15 14:32:42

Re: systemd? why?

#18 2012-04-15 16:39:33

Re: systemd? why?

#19 2012-04-16 22:40:05

Re: systemd? why?

Board footer