Arch Linux Is Switching To Systemd

[0xCAFE]

My systemctl completes fine in zsh.

sudo systemctl restart post[tab] => sudo systemctl restart postgresql.service

But it doesn't seem to always work well yet...

It completes in bash on Fedora as well.

[liam]

I stopped using my installation of Arch when upgrading offered NO OPTION but to install systemd.

My experience with other distros using systemd is: If it works you don't even know its there.
If it doesn't work YOU, the user have little control, or knowledge, of how to fix it.

My view is that systemd is a complicated solution looking for a problem to fix.
I had NO PROBLEMS with booting, that I could not fix, until systemd came along.

If you just use the basic install a distro gives you, likely you won't care about systemd.
Assuming the distro developers can learn how to setup and use systemd.

If you are a tweaker, and like to change things, systemd has a LONG way to go before it is usable.
Perhaps in the future 3rd party developers will produce an interface for humans to control systemd.
Until that time I still have other options. Debian and slackware to name a couple.

Systemd is easy to use and BACKWARDS COMPATIBLE with sysvinit. Also has spectacular docs.
Really, if you are a tweaker, systemd is great.
Also, fast boot is only a small part of what it brings. A much bigger win is that it makes handling services so easy and it manages their lifecycle.

On a side note, Lennart might want to change his name, or at least act as a ghost coder for someone else. That would get rid of these stupid arguments.

[liam]

I am pretty sure you have your wires crossed on the rt daemon thing since I have been around on the LAD and LAU mailing lists while this has been happening. My understanding goes like this - the method for RT that jack currently uses introduces security issues such that distros such as debian don't want to turn it on by default... The current compromise is that debian based distros at least give you the option to turn it on when you install jack. What Lennart proposed (and implemented) was an alternative method of getting realtime privileges that offered extra security against some forms of attack. He wrote to the linux audio crowd to inform them that an alternative way of getting realtime privileges was available. The jack crowd understandably had previously been told that they way that they were doing things was acceptable and to my knowledge has stuck to the way that they are doing things. I don't think a daemon (other than pulse or jack) is involved in this process at all. -

Rtkit was the solution lennart came up with, and it does run as a daemon. Apps have to be written to take advantage if it, though.

[sabriah]

Its change and in neckbeard speak Change is evil. Even if its for the better.

Neckbeard?! I got it!

[WorBlux]

So what makes systemd so awesome?

I starts up services massively in parallel. Socket based activation allows you to start a service before it's dependencies are fully initialized. Things will stall only if you fill up the socket pipeline or a response is required.

Services are controlled by putting them in c-groups, they can't escape control of the init system.

You can boot to a X without starting any shells.

Use of autoFS, allows you to continue even though some disks may not be initialized, you only stall if some piece of critical data is missing.

Read-ahead can optimize disk access to further decrease boot times.

Integration into other methods of starting services. A service can be started at boot because it is a dependency of another, in response to a hardware event, or as a cron job.

Potential to be not just an init manager, but a session manager as well.

Searchable logs

And in general a more integrated, yet still modular core system, that is smaller and easier to manage than if they were completely separate as they are now.

The potential to standardize certain config files and init files across distros.

Minimal distruption to current practices (system V compatibility, as well as most modules supporting prior interface methods)

[TobiSGD]

The real problem with systemd is not that it is another init system. If it would be and it worked fine there would be no reason not to use it, except if it just doesn't fit your needs.
The real problem is that the developers want systemd to be more than an init system. They also want it to be a replacement for udev (udev is now integrated into systemd, will work outside of systemd, but will not get any changes for this "outside of systemd"-function), a system logger, a session manager and whatever the developers come up in the future.

This stands in direct opposition to the Unix philosophy (one tool for one purpose) and even more in direct opposition to the KISS philosophy.

IMHO, with the change to systemd Arch developers have lost any reason to keep this line on their Wiki:

The following five core principles comprise what is commonly referred to as the Arch Way, or the Arch Philosophy, perhaps best summarized by the acronym KISS for Keep It Simple, Stupid.

I am glad the the developers of my preferred distro are not willing to make the change to systemd, because they really follow the KISS principle and the Unix philosophy.
Thanks, Mr. Volkerding.

[89c51]

The real problem with systemd is not that it is another init system. If it would be and it worked fine there would be no reason not to use it, except if it just doesn't fit your needs.
The real problem is that the developers want systemd to be more than an init system. They also want it to be a replacement for udev (udev is now integrated into systemd, will work outside of systemd, but will not get any changes for this "outside of systemd"-function), a system logger, a session manager and whatever the developers come up in the future.

This stands in direct opposition to the Unix philosophy (one tool for one purpose) and even more in direct opposition to the KISS philosophy.

IMHO, with the change to systemd Arch developers have lost any reason to keep this line on their Wiki:

I am glad the the developers of my preferred distro are not willing to make the change to systemd, because they really follow the KISS principle and the Unix philosophy.
Thanks, Mr. Volkerding.

Apart of the "Unix philosophy" bullshit is there any technical reason not to do it?

[tstrunk]

This stands in direct opposition to the Unix philosophy (one tool for one purpose) and even more in direct opposition to the KISS philosophy.

I disagree that introducing systemd is against the KISS philosophy:
Many packages nowadays are tailored towards it (udev was mentioned in this thread). Starting daemons without systemd will be the non-standard way in years to come. Archlinux has always been about keeping packages mostly vanilla, i.e. minimum amount of patches, pushing really needed fixes upstream.
Therefore they have a good reason to go to systemd: it will be standard soon and require the least amount of work, also on the dev side.

[TobiSGD]

Apart of the "Unix philosophy" bullshit is there any technical reason not to do it?

May be the reason that it is in no way a good idea to replace several mature programs with a hyped one, so that a single point of failure can bring your whole system down? Have problems with systemd? Well, look at the logs! Oh, wait, the logger is a part of systemd, .. . There is an endless way of putting such combinations together.
By the way, think about how much GNU/Linux you would have today without the "Unix philosophy bullshit".

I see people saying here "It will be standard soon!". May I ask what gives you the impression? The distributions that have the most users and the most derivatives (Ubuntu and Debian) are not using it. I would like to see a statistic how many distributions (with an estimation of their user bases) in reality do use systemd and how many use different init systems before talking about standards. Who declares such standards (Red Hat, the ones with the largest revenue or Canonical, the ones with the largest userbase, or Debian, the one were most distros are built upon, or Slackware the oldest alive distribution, or ...)?

[Zorael]

I've been running it on Kubuntu for a while now, and it works very well. It was a royal pain to get set up though; lots of core stuff have upstart as a hard dependency. Moreover many installation scripts call upstart's initctl directly, so I had to write a wrapper to fix package installation. So currently upstart stays installed alongside it currently. Preferably init implementation packages should provide an 'init' virtual package, but I don't see Canonical having any interest in anything other than upstart, so I'm not holding my breath.

As a small note, the systemd in Debian's repositories (44?) is ancient.

The real problem with systemd is not that it is another init system. If it would be and it worked fine there would be no reason not to use it, except if it just doesn't fit your needs.
The real problem is that the developers want systemd to be more than an init system. They also want it to be a replacement for udev (udev is now integrated into systemd, will work outside of systemd, but will not get any changes for this "outside of systemd"-function), a system logger, a session manager and whatever the developers come up in the future.
This stands in direct opposition to the Unix philosophy (one tool for one purpose) and even more in direct opposition to the KISS philosophy.

In a sense yes, and in a sense no.

Remember that /bin/systemd is not all of systemd! The project strives to supply reference implementations of common functionality, but the accusations of monolithically trying to do everything is sort-of true yet largely unwarranted. Inarguably, beyond the pid 1 init system you have those services that set the hostname, the almost-syslog journal, readahead, random seed saver/loader, dumbed-down bootchart, login session manager (think ConsoleKit's ck-list-sessions), etc etc. But not only are they all compile-time options; they're also easily disabled in runtime.

Regarding udev, the "system and service manager" that is /bin/systemd wants to monitor software and hardware events (as reported by udev), so as to be able to act thereupon. As far as I understand, the codebase became so tightly shared with udev that marrying them into one was deemed the best course of action. Given sane packaging udev shouldn't necessarily depend on systemd, though the other way around will very very likely apply.

zorael@laughlyn /main/src/systemd$ ./configure --help
[I][b][...][/b][/I]
  --disable-ima           Disable optional IMA support
  --disable-selinux       Disable optional SELINUX support
  --disable-xz            Disable optional XZ support
  --disable-tcpwrap       Disable optional TCP wrappers support
  --disable-pam           Disable optional PAM support
  --disable-acl           Disable optional ACL support
  --disable-audit         Disable optional AUDIT support
  --disable-libcryptsetup disable libcryptsetup tools
  --disable-binfmt        disable binfmt tool
  --disable-vconsole      disable vconsole tool
  --disable-readahead     disable readahead tools
  --disable-quotacheck    disable quotacheck tools
  --disable-randomseed    disable randomseed tools
  --disable-logind        disable login daemon
  --disable-hostnamed     disable hostname daemon
  --disable-timedated     disable timedate daemon
  --disable-localed       disable locale daemon
  --disable-coredump      disable coredump hook
  --disable-gudev         disable Gobject libudev support [default=enabled]
  --disable-keymap        disable keymap fixup support [default=enabled]
[I][b][...][/b][/I]

$ systemctl list-units --all --full | grep '^systemd'
systemd-ask-password-console.path              loaded active   waiting       Dispatch Password Requests to Console Directory Watch
systemd-ask-password-wall.path                 loaded active   waiting       Forward Password Requests to Wall Directory Watch
systemd-ask-password-console.service           loaded inactive dead          Dispatch Password Requests to Console
systemd-ask-password-wall.service              loaded inactive dead          Forward Password Requests to Wall
systemd-binfmt.service                         loaded inactive dead          Set Up Additional Binary Formats
systemd-fsck-root.service                      loaded inactive dead          File System Check on Root Device
[email protected]                  loaded inactive dead          File System Check on /dev/sda2
[email protected]                  loaded inactive dead          File System Check on /dev/sda4
systemd-initctl.service                        loaded inactive dead          /dev/initctl Compatibility Daemon
systemd-journal-flush.service                  loaded inactive dead          Trigger Flushing of Journal to Persistent Storage
systemd-journald.service                       loaded active   running       Journal Service
systemd-logind.service                         loaded active   running       Login Service
systemd-modules-load.service                   loaded active   exited        Load Kernel Modules
systemd-random-seed-load.service               loaded inactive dead          Load Random Seed
systemd-random-seed-save.service               loaded inactive dead          Save Random Seed
systemd-readahead-collect.service              loaded active   exited        Collect Read-Ahead Data
systemd-readahead-done.service                 loaded inactive dead          Stop Read-Ahead Data Collection
systemd-readahead-replay.service               loaded active   exited        Replay Read-Ahead Data
systemd-remount-fs.service                     loaded active   exited        Remount Root and Kernel File Systems
systemd-shutdownd.service                      loaded inactive dead          Delayed Shutdown Service
systemd-sysctl.service                         loaded active   exited        Apply Kernel Variables
systemd-tmpfiles-clean.service                 loaded inactive dead          Cleanup of Temporary Directories
systemd-tmpfiles-setup.service                 loaded active   exited        Recreate Volatile Files and Directories
systemd-udev-settle.service                    loaded active   exited        udev Wait for Complete Device Initialization
systemd-udev-trigger.service                   loaded active   exited        udev Coldplug all Devices
systemd-udevd.service                          loaded inactive dead          udev Kernel Device Manager
systemd-update-utmp-shutdown.service           masked inactive dead          systemd-update-utmp-shutdown.service
systemd-user-sessions.service                  loaded active   exited        Permit User Sessions
systemd-initctl.socket                         loaded active   listening     /dev/initctl Compatibility Named Pipe
systemd-journald.socket                        loaded active   running       Journal Socket
systemd-shutdownd.socket                       loaded active   listening     Delayed Shutdown Socket
systemd-udevd-control.socket                   loaded active   listening     udev Control Socket
systemd-udevd-kernel.socket                    loaded failed   failed        udev Kernel Socket
systemd-readahead-done.timer                   loaded active   elapsed       Stop Read-Ahead Data Collection 10s After Completed Startup
systemd-tmpfiles-clean.timer                   loaded active   waiting       Daily Cleanup of Temporary Directories

I simply chose to not build some of the tools; vconsole, quotacheck, hostnamed, timedated, localed, coredump; since I don't need them. If I was installing from a package and they had all been prebuilt for me;

$ sudo systemctl [B][COLOR="red"]disable[/COLOR] systemd-readahead-{collect,drop,replay}.service[/B]
rm '/etc/systemd/system/system-update.target.wants/systemd-readahead-drop.service'
rm '/etc/systemd/system/default.target.wants/systemd-readahead-replay.service'
rm '/etc/systemd/system/default.target.wants/systemd-readahead-collect.service'

So in summary, the systemd project tries to modularly provide everything you need to get a fully functional userspace set up. The systemd binary doesn't bloat itself with those bits; it merely sets itself up as a service monitor that in turn starts them. And you can opt out of (almost) all of it and use dedicated daemons instead.

As for software design, Poettering seems to be of the opinion that UNIX philosophy shouldn't be in the way of smart ideas. The same for portability, apparently; "dumbing it down" to adhere to the lowest common denominator, such as by not using control groups, has its drawbacks.