systemd: Yet Another Init Replacement

falconindy · 2010-07-26 12:27:15

ajk wrote:

Did anyone try systemd allready on their Arch Linux system? I just build v4 but the network still doesn't come up by default.. Anyone has a clue on how to fix this?

The arch initscripts are lacking the LSB compliant headers that systemd reads as a fallback when unit files are missing. Either add the header or write the service file.

Also, based on the way the PKGBUILD for systemd v2 is written, I'd guess that you're suffering from what I posted (and fixed in systemd-git) above about udev and dbus not starting. You'll need to fix that before you can consider getting systemd to start services on boot.

Last edited by falconindy (2010-07-26 12:29:24)

theDOC · 2010-08-25 20:45:42

I just tried systemd-git today and got it working. I had to fix some docbook stuff and needed to patch the kernel so it creates /sys/fs/cgroup. Without changing anything it booted to a working login shell. It seemed to just call rc.sysinit somewhere, don't know if all thats in there is really needed or could be handled by systemd in some other nice way...
With the tool systemctl you can start/stop units and I was able to start /etc/rc.d scripts simply by appending ".service" to the name. Like "systemctl start networkmanager.service". So, LSB headers seem not to be needed anymore.
I also linked and created some .target-files in the *.want directories and got my system to boot straight to gdm.

Maybe my recap helps anyone who wants to try systemd too...

damjan · 2010-08-27 16:00:10

theDOC wrote:

...needed to patch the kernel so it creates /sys/fs/cgroup...

what patch is that?

theDOC · 2010-08-27 16:31:52

this one:
http://lkml.org/lkml/2010/7/22/384

falconindy · 2010-08-29 21:04:10

theDOC wrote:

I just tried systemd-git today and got it working. I had to fix some docbook stuff and needed to patch the kernel so it creates /sys/fs/cgroup. Without changing anything it booted to a working login shell. It seemed to just call rc.sysinit somewhere, don't know if all thats in there is really needed or could be handled by systemd in some other nice way...
With the tool systemctl you can start/stop units and I was able to start /etc/rc.d scripts simply by appending ".service" to the name. Like "systemctl start networkmanager.service". So, LSB headers seem not to be needed anymore.
I also linked and created some .target-files in the *.want directories and got my system to boot straight to gdm.
Maybe my recap helps anyone who wants to try systemd too...

I'm curious about this... I'm able to get a booting system, but I can't seem to mimic the behavior of appending .service to get the /etc/rc.d files to work through systemctl. I'm showing errors similar to:

Failed to issue method call: Unit crond.service failed to load: Invalid argument. You might find more information in the logs.

Logs seem clean at the current verbosity level. The only units that dont complain are dbus, udev and syslog-ng, because they're handled at compile or install time.

theDOC · 2010-08-29 23:44:00

falconindy wrote:

I'm curious about this... I'm able to get a booting system, but I can't seem to mimic the behavior of appending .service to get the /etc/rc.d files to work through systemctl. I'm showing errors similar to:
Failed to issue method call: Unit crond.service failed to load: Invalid argument. You might find more information in the logs.

That is strange, for me it works on every rc.d file. When did you build systemd the last time? They did a lot of commits in the last few days.

falconindy wrote:

Logs seem clean at the current verbosity level. The only units that dont complain are dbus, udev and syslog-ng, because they're handled at compile or install time.

I think systemd looks if there is a real .service file and only if it doesn't find one, calls the corresponding rc.d script. So, since you installed the systemd versions of udev and dbus you should have those files and thats why they work. I don't know why syslog-ng works though. There is a syslog.target that calls syslog-ng.service but no .service file...

falconindy · 2010-08-29 23:48:16

Build Date     : Sun 29 Aug 2010 04:37:55 PM EDT
Install Date   : Sun 29 Aug 2010 04:37:57 PM EDT

I think I'm up to date =P

syslog-ng is a special service defined at compile time. There's some voodoo in the ./configure that detects the distro as being Arch and sets some directories and services. Check out systemd.special(7).

theDOC · 2010-08-30 00:36:04

I just rebuilt it, still working... Did you rebuild dbus-git too, I think the "Invalid argument" part of your error message is coming directly from dbus.

falconindy · 2010-08-30 00:51:26

dbus is a fresh pull from tonight as well. Hrmm, I'll talk to Lennart. He's always been extremely patient and helpful.

falconindy · 2010-08-30 11:31:08

@theDOC: if you don't mind, could you post the output of 'systemctl status <unit>' for a few of your rc.d services?

theDOC · 2010-08-30 12:34:58

here it is:
http://pastebin.com/esZqeYKw

falconindy · 2010-08-30 17:37:48

Wild... I rebooted with systemd set to log-level=debug, and I can't reproduce. Units start and stop just fine.

falconindy · 2010-08-30 22:46:55

Fixed! Ok, so you can't symlink /etc/rc.d/ initscripts into the *.wants -- you can create the old standard /etc/rcN.d hierarchy and symlink them in there, or you can create a native unit file for the service and put that in a *.wants. Unit files for services are easy. For example, MPD's script would look like this:

[Unit]
Description=Music Player Daemon

[Service]
Type=forking
PIDFile=/var/run/mpd.pid
ExecStart=/etc/rc.d/mpd start
ExecStop=/etc/rc.d/mpd stop
ExecReload=/etc/rc.d/mpd reload

Or you can go one step further and just cut out the crap since its a really simple initscript:

[Unit]
Description=Music Player Daemon

[Service]
ExecStart=/usr/bin/mpd --no-daemon /etc/mpd.conf
Restart=restart-always
RestartSec=1

The stop and restart actions are implicitly handled by systemd. Note that whenever possible, it's advisable to declare the daemon as Type=simple (the default) and prevent the daemon from forking on its own. Systemd will fork it for you and in turn will have much better control over the service.

Update: I've been plugging away at creating some unit files and I feel like I've made some actual progress. I've got an AUR package created which backs up onto a git repo. With a few other tweaks and a fair bit of nagging in the direction of Lennart, and I've got a fairly solid setup going.

Last edited by falconindy (2010-09-01 02:50:22)

jiu · 2010-09-16 12:02:28

I'd be interested to hear of the benefits (performance? simplicity? control?) that this approach brings.

theDOC · 2010-09-16 13:21:55

here is an article about systemd, what it does, why and how:
http://0pointer.de/blog/projects/systemd.html

intgr · 2010-09-16 13:33:50

This is a partial list of reasons that I could think of, why systemd is great. This is not an exhaustive list, systemd does even more than this.

I will also take this chance to say: Thanks falconindy, for all your hard work with integrating systemd into Arch! Also thanks to Lennart for coming up with the ideas and implementation!

jiu wrote:

performance?

As an example, dependency-based systems like Upstart or OpenRC have to start DBus, wait until it's ready, and then start network-manager.
systemd can start dbus and network-manager at the same time; only if network-manager tries to connect to DBus before DBus is ready, only then will network-manager have to wait. Otherwise they can start in parallel
Similar things apply to systemd's lazy-mounting of file systems -- your Apache can start up even when /home is still pending a fsck

jiu wrote:

simplicity?

I'm one of those people who never liked the current approach of managing init scripts. There are hundreds of variations of initscripts; every distro has totally different styles of writing them (Arch has add_daemon/rm_daemon, Debian has start-stop-daemon, Fedora has something else entirely), and then the scripts are copied and adapted, often modified slightly. Changes/fixes in the initscript "base template" often don't propagate to packages even if they should.

Life is much easier if we have standardized init configuration syntax and well-defined semantics. Init configuration will also be much shorter and thus more easily comprehensible.
This also fits well into Arch's "ship upstream stuff unmodified" philosophy: Arch maintainers won't have to write custom initscripts for all packages, but can use upstream's and contribute their patches back if necessary.
Unlike Upstart, systemd inherently has implicit dependencies. For instance, depending on configuration, Postfix may or may not depend on MySQL. With Upstart/OpenRC, the init script writer does not know the specific configuration of Postfix on your system, thus they cannot know whether it depends on MySQL or not.
With systemd, implicit dependencies will sort it out. When MySQL is enabled, but not configured for startup, and Postfix tries to connect to it, then MySQL is started implicitly because there was a connection on MySQL's socket.

jiu wrote:

control?

Compared to the Arch Way with rc.conf, you will definitely lose some control. systemd will take care of parallelizing/ordering init scripts. Even though I appreciate the simplicity and transparency of DAEMONS=(), I prefer systemd.
There's also the advantage that (like Upstart), systemd will be able to restart crashed daemons.
systemd assigns cgroups to all daemons, so you can easily restrict their resource usage in ways that is not possible otherwise. /etc/security/limits.conf is very limited and has always been borderline useless because it only applies to each single process individually, not a daemon as a whole.
systemd is capable of tracking down and killing all child processes of a daemon. E.g., when a nasty CGI script has escaped from Apache and is stuck in an infinite loop.

There's also elegance:

The systemd inherently knows whether a spawned daemon is running or not. With classic initscripts, you often run into situations where the script thinks a daemon is not running (because the pidfile was deleted or whatever), but start fails because it actually is running.
Storing running-state information like pidfiles on disk is simply silly. They shouldn't persist through reboots, they should only be in RAM. Mounting tmpfs on /var/run is also a hack.
Systemd can bind privileged ports (e.g. port 80 for Apache) itself and pass the socket on to Apache -- services won't have to start as root and do their own privilege dropping anymore.

Last edited by intgr (2010-09-16 13:35:18)

zenlord · 2010-09-16 13:57:41

@intgr: thx for this very concise wrap-up - it has gotten me interested in this. 1 little question: you don't say it explicitly, but is there a real speed-advantage on your own system (irl and not theoretically)?

intgr · 2010-09-16 14:26:06

zenlord wrote:

is there a real speed-advantage on your own system (irl and not theoretically)?

For now, the improvement is quite small.

Some of what I described above still require work on Arch's side:

daemons need to be patched in order to accept their socket from systemd. Until then, systemd is as good as dependency-based init systems
Correct me if I'm wrong, but AFAICT, the "early boot" is still done using Arch's init scripts and takes a significant amount of time; some of that will need to be rewritten to take advantage of systemd
Somehow Arch's kernel takes a while to initialize, there is nothing that systemd can do about it

Last edited by intgr (2010-09-16 14:27:18)

falconindy · 2010-09-17 03:04:21

intgr wrote:

Some of what I described above still require work on Arch's side:
* Correct me if I'm wrong, but AFAICT, the "early boot" is still done using Arch's init scripts and takes a significant amount of time; some of that will need to be rewritten to take advantage of systemd

I've done some work on this. I've got /etc/rc.sysinit down to 282 lines (knocking off roughly 100 or so). My personal rc.sysinit removes all the mdadm, lvm, and crypto crap dropping the line count down to 163. Still to be implemented by Systemd are things like fsck and natively rebooting. Since systemd was turned down by FESCO for FC14 and postponed until FC15, Lennart wants to move from bug patching mode to adding more features such as the ones previously mentioned. If anyone wants to figure out how to remove more of this (local-fs.target should make arch's root mounting voodoo superfluous but I've been unsuccessful thus far), pull requests on GitHub are extremely welcome.

intgr wrote:

* Somehow Arch's kernel takes a while to initialize, there is nothing that systemd can do about it

Not sure what this means... are you talking about the initcpio? A GNU/Linux kernel is a GNU/Linux kernel.

After several people asked me "is there any doc?" I finally got around to writing up something about the whole installation procedure. Most of it belongs in the Wiki, but I don't currently have the time to do that translation.

intgr · 2010-09-17 07:17:58

falconindy wrote:

intgr wrote:
* Somehow Arch's kernel takes a while to initialize, there is nothing that systemd can do about it
Not sure what this means... are you talking about the initcpio? A GNU/Linux kernel is a GNU/Linux kernel.

I could be wrong about this, but it's just an observation that Arch seems to spend longer in the kernel initialization than distros like Ubuntu. Not surprising because they have spent more time optimizing their boot. No, a kernel is not a kernel; there are different versions, the behavior also very much depends on the kernel configuration and other distros frequently apply heaps of patches to mainline kernels. So they can be quite different from what Arch ships.

PS: that's "Linux kernel" not "GNU/Linux kernel"

Zom · 2010-09-17 09:51:40

Created an initial article on the wiki, based on falconindys blog article.

falconindy · 2010-09-17 10:21:40

intgr wrote:

PS: that's "Linux kernel" not "GNU/Linux kernel"

Is it still only a Linux kernel even after its compiled with a GNU toolchain?

Zom wrote:

Created an initial article on the wiki, based on falconindys blog article.

Wow, that was fast. Thanks!

Zom · 2010-09-17 10:52:06

falconindy wrote:

intgr wrote:
PS: that's "Linux kernel" not "GNU/Linux kernel"
Is it still only a Linux kernel even after its compiled with a GNU toolchain?

AFAIK, the code is still pure Linux. It has nothing to do with whatever compiler you choose to use.

Granted, I might not have the best understanding in the matter.

falconindy wrote:

Wow, that was fast. Thanks!

You're welcome, I'm happy to help.

Last edited by Zom (2010-09-17 10:52:45)

intgr · 2010-09-17 10:52:32

falconindy wrote:

intgr wrote:
PS: that's "Linux kernel" not "GNU/Linux kernel"
Is it still only a Linux kernel even after its compiled with a GNU toolchain?

Is PostgreSQL called Microsoft/PostgreSQL when built with the MSVC toolchain?

Sorry, didn't want to take it this far but I just had to say it.

falconindy · 2010-09-19 19:40:28

I'm now maintaining the stable version of systemd as well for those not interested in pulling from git.

Arch Linux

#26 2010-07-26 12:27:15

Re: systemd: Yet Another Init Replacement

#27 2010-08-25 20:45:42

Re: systemd: Yet Another Init Replacement

#28 2010-08-27 16:00:10

Re: systemd: Yet Another Init Replacement

#29 2010-08-27 16:31:52

Re: systemd: Yet Another Init Replacement

#30 2010-08-29 21:04:10

Re: systemd: Yet Another Init Replacement

#31 2010-08-29 23:44:00

Re: systemd: Yet Another Init Replacement

#32 2010-08-29 23:48:16

Re: systemd: Yet Another Init Replacement

#33 2010-08-30 00:36:04

Re: systemd: Yet Another Init Replacement

#34 2010-08-30 00:51:26

Re: systemd: Yet Another Init Replacement

#35 2010-08-30 11:31:08

Re: systemd: Yet Another Init Replacement

#36 2010-08-30 12:34:58

Re: systemd: Yet Another Init Replacement

#37 2010-08-30 17:37:48

Re: systemd: Yet Another Init Replacement

#38 2010-08-30 22:46:55

Re: systemd: Yet Another Init Replacement

#39 2010-09-16 12:02:28

Re: systemd: Yet Another Init Replacement

#40 2010-09-16 13:21:55

Re: systemd: Yet Another Init Replacement

#41 2010-09-16 13:33:50

Re: systemd: Yet Another Init Replacement

#42 2010-09-16 13:57:41

Re: systemd: Yet Another Init Replacement

#43 2010-09-16 14:26:06

Re: systemd: Yet Another Init Replacement

#44 2010-09-17 03:04:21

Re: systemd: Yet Another Init Replacement

#45 2010-09-17 07:17:58

Re: systemd: Yet Another Init Replacement

#46 2010-09-17 09:51:40

Re: systemd: Yet Another Init Replacement

#47 2010-09-17 10:21:40

Re: systemd: Yet Another Init Replacement

#48 2010-09-17 10:52:06

Re: systemd: Yet Another Init Replacement

#49 2010-09-17 10:52:32

Re: systemd: Yet Another Init Replacement

#50 2010-09-19 19:40:28

Re: systemd: Yet Another Init Replacement

Board footer