
What should we expect from a modern init system? - martius
https://plus.google.com/u/0/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT
======
mverwijs
I still do not understand what problem upstart or systemd are trying to solve.
Slow boot times? Have you ever even booted an HP DL360? Or any server? Of the
entire 8 minute or so process, sysv init only takes up 10 seconds. So what is
the problem?

Containers of Debian 7 (openvz) start in seconds, with sysv init. My laptop
dito.

What am I missing? Android? That takes forever to boot and I have no idea why.
Could be that systemd fixes that problem.

To me, Systemd and upstart come across as modern-for-the-sake-of-being-modern.

~~~
dsr_
My LG G2, running android 4.2.2 with a 3.2.0 kernel, boots in about eight
seconds from cold. It also has the best battery life of any smartphone I've
ever seen (24+ hours, of which 8+ with screen on and doing things is normal on
any day that I don't play 3D games.) SysVinit.

My boring house server, AMD FX4130, boots from a small Intel SSD in forty
seconds from power to 0 load. Debian stable, sysVinit.

I understand sysVinit. I can debug it. When things go wrong, I can stop it,
figure it out, fix it and start it again.

Being able to figure things out and fix them is the heart of UNIX. I'm not
against progress, I'm against screwing things up in the name of progress.

OpenRC looks interesting.

~~~
rodgerd
> I understand sysVinit. I can debug it. When things go wrong, I can stop it,
> figure it out, fix it and start it again.

"I don't want to learn new things. I labour under the delusion that tens of
thousands of lines of shell code is a clean solution" is all I hear.

~~~
mverwijs
Then you did not read or failed to understand the line that came after the one
you quoted.

------
brokenparser
I expect an init system to be an init system, not to also be pm-utils,
(x)inetd, acpid, syslogd, watchdog, cron and atd. I also expect it to have
configuration files I can change, not to have everything symlinked to /usr.
(If I can even find the right configuration file in that mess of directories,
that is.)

~~~
exDM69
> I expect an init system to be an init system, not to also be pm-utils,
> (x)inetd, acpid, syslogd, watchdog, cron and atd.

The problem with this traditional unix approach is that in addition to init,
pm-utils, inetd, cron, etc you end up having thousands of lines of shell
scripts that glue all this together in a big brittle mess.

While this approach may be fine for servers which boot once and stay on for
ages, are connected to fast wired network and are generally rather stable
configurations, I don't want such a system for my desktop, laptop or mobile
device.

I expect modern devices to be able to deal with changes in power supply
(battery/mains/low battery), connecting and disconnecting devices (storage,
peripherals, audio devices, etc) and changes in network connectivity
(intentional disconnection as well as network failure). This may involve
starting and stopping services, mounting and unmounting partitions and taking
other actions when the physical configuration changes.

I also expect my computers to boot and shutdown quickly and effectively.

Some of this is already doable in other systems, like the traditional Debian
network setup (originally built in the era of wired networks) which can run
scripts on connect/disconnect. But the situation ends up being what I
described above: thousands of lines of brittle shell scripts.

I welcome the changes and the effort put in systemd and other init systems.
Traditional unix init just doesn't cut it any more, in particular on personal
desktop and mobile devices.

~~~
Zancarius
I had my reservations when Arch shifted to systemd. It seems like a tremendous
break from Unix philosophy and a blatant violation of everything I knew.

I'm glad they did, though. Unit files are far easier to write and having a
supervisor behavior in the init system alleviates a tremendous amount of
administrative overhead. That's not to say shell scripts are difficult, but
they can break in mysterious ways. Though I imagine the same is true for
systemd, from an end user perspective, its implementation (once you understand
it) requires less effort.

There are those who disagree, and I respect that. But the improvements to my
desktop boot time are substantial. And writing a quick unit file to run
something on boot requires little mental overhead. Just a glance over the
manpage is enough to get started. sysvinit scripts on the other hand... well,
maybe my memory is really poor, but if it's been more than a few months since
I've written one for the specific system I'm targeting, it takes substantially
longer. ;)

So, it's likely I'm stupid or systemd is easier. Or both. Probably both.

~~~
unhammer
I had the same experience, would not have expected to be so pleasantly
surprised by an init system :) And writing unit files for systemd was
fantastically easy.

systemd actually looks like it was _designed based on experience_. "Worse is
Better" as a development philosophy works for getting stuff up and running and
finding out what the real problems are so that you don't make solutions for
non-existent problems. But when enough time has passed, and enough glue and
pieces of string accumulated, it's time to take a step back and consider a
redesign.

~~~
Zancarius
I think that's my biggest problem with shell-scripts-as-an-init-system.
There's nothing inherently _wrong_ with it, but sooner or later, the only way
to correct for broken or missing functionality is (to borrow your term) to add
more glue. And if you want more correct behavior, you either have to wait for
the distro maintainers to fix it or fix it yourself only to merge your changes
back in on the next OS update.

That's another thing I like about systemd. With the separation of "stock" unit
files in /usr/lib and user-supplied ones in /etc/systemd, you can override the
ones distributed by your OS vendor without worrying about updates breaking
your changes. That's already saved me once or twice during Arch's transition
from sysvinit to systemd, in fact.

One thing that comes to mind is an issue I had some time back with running a
proprietary service in a manner that would allow the init system to control it
when it forked itself a number of times and spun up separate processes. start-
stop-daemon was confused by this behavior and it required some tricks to
collect the approriate PID just to be able to stop the service (I may be
wrong, but I think it was the TeamSpeak 3 daemon which behaves weirdly).
systemd's use of cgroups ignores this rubbish entirely, because it's
effectively impossible for systemd to lose track of what processes belong to
which service. Want to kill the service? No problem.

Some in this thread seem convinced that systemd is a solution looking for a
problem, but I suspect some of them lack experience with systemd. Or
stubbornly cling to their ideals of what an init system should do. I like the
unification of a supervisor-type service and the init system. It makes my job
easier. And that's not even half of what systemd is capable of!

------
Myk267
Does anyone else feel like the only reason to choose systemd is the systemd-
journal? That thing is just amazing. The amount of leverage provided by not
just appending to a log file somewhere will really get the juices moving in
anyone who ever had to write some ad-hoc parser to do the same thing poorly.

If anyone hasn't tried out systemd or journalctl yet, I suggest running a copy
of Arch Linux in a virtual machine.

~~~
Zancarius
I think the unit files are another reason. Over the years, my patience with
differing ideas of how an initscript should function has waned to the point
that it's almost an exercise in frustration if it's not something you
regularly write on a platform you seldom use. Unit files alone make systemd a
breath of fresh air, because familiarizing yourself with them requires reading
only the manpages (and even then only the applicable portions). Even somewhat
esoteric behaviors are readily supported without much effort.

I realize initscripts are "simple" in the sense that they borrow immediately
from the shell and therefore possess all the advantages (and disadvantages)
implied by such. Unfortunately, the notion of a sane initscript seems to be
greatly varied in the sense that it depends largely on the distribution and
the package maintainers. It isn't that they're necessarily difficult to write
as much as having the power of the shell available inclines some authors to do
very stupid things.

Comparatively speaking, a unit file should be exceptionally easy to understand
at first blush.

------
samworm
I personally prefer systemd to upstart. I just hope that distros (in this case
Debian) stick to a technical review and don't get drawn into ad hominem
arguments.

For many people it seems the answer to the question posed in the post title is
"I would expect it to not be designed/authored by the man behind pulseaudio".

~~~
martius
One argument that is on the edge: Lennart often takes controversial decisions,
and in the case of systemd, he refuses portability patches that would allow
systemd to run on other unixes than Linux (BSD, Hurd, etc).

Since debian is supposed to be universal (hence, support alternative Unix
kernels), choosing systemd barely means that they will have to drop this trait
of the distribution.

~~~
bkor
Various features that systemd exposes have no equivalent in other kernels.
This makes it impossible. He also explained various times why he refuses non-
complete portability patches. This because you get more ifdefs and those are
difficult to test/guarantee.

He and Kay claimed that kdbus couldn't be used for Binder as well. Greg
thought it was possible. Only after writing kdbus he came to the conclusion
that Lennart+Kay had it right.

Suggest to write a complete patch to make systemd work on FreeBSD. I assume
you'll discover Lennart is right :-P

~~~
martius
Actually, feasible or not, I understand and somewhat agree with the fact that
they don't want portability patches, it would probably force systemd to be
limited to the lowest common denominator and add a lot of complexity to the
project.

However, I was wondering if platform-specific forks are a sustainable
solution.

------
atmosx
I'm tired reading about this. It seems to boil down to politics, mostly and
features less... The team with the _better players_ will win this.

What is interesting though, is to see how the BSD ecosystem will handle this.
Will they adapt in time or they will lag even further behind this?

* NetBSD might reached the point of virtual insignificance long time ago.

* OpenBSD is out of funds - which is a shame considering the software they produced (PF, OpenSSH, OpenNTPD), but their indifference for desktop makes them obsolete.

* FreeBSD (I use it in both my servers) is the most up-to-date but now with system-d/upstart not supported, I think they will run into trouble relative soon.

Darwin said it best: _the ones most adaptable to change survive_. Of course,
the other happy scenario is that given the fact that these OSes power some
big-corp servers, these big-corps will step in and fund these projects, I
wouldn't hold my breath though.

~~~
rodgerd
I'm pretty sure that FreeBSD are ressurecting their OS X-derived launchd
experiment to get a better init.

The argument that sysv "is Unix" is pretty much horseshit at this point.
Solaris and OS X don't use a sysv style init, most of Linux doesn't any more
(either upstart or systemd). At this point one is redefining "real Unix" down
to NetBSD and HP-UX.

~~~
profquail
Here's the link to the port-in-progress of launchd to FreeBSD, if anyone is
curious:

[https://github.com/rtyler/openlaunchd](https://github.com/rtyler/openlaunchd)

------
nitrogen
I would prefer a parallelized dependency-based init system over an event-
triggered system. I want to be able to say "start openssh" and have networking
start with it automatically, for example, like Gentoo used to have (or still
does?).

~~~
mverwijs
I would prefer to do my own thinking, not have the computer try to outsmart
me. It can't, and it always hurts my sleepcycles when it tries.

~~~
forgottenpass
You already have an init system that does some level of "thinking" for you.
You had to learn how that one works, you just don't want to learn a new one.

~~~
mverwijs
> You had to learn how that one works, > you just don't want to learn a new
> one.

That conclusion was quickly drawn. :)

------
chousuke
Personally, I prefer systemd. I have quite a shallow understanding of upstart,
but even so I find a dependency-based model much easier to reason about than
an event-based model.

I'm quite sure either would be a massive improvement over sysvinit though.

------
scarmig
PulseAudio was wonky in 2005, therefore sysvinit forever.

~~~
sparkie
PulseA _blip_ udio is still wonky in 2014 if you need to use it alongside
JACK.

~~~
bkor
You can easily pause pulseaudio while the Jack program is running. I saw the
development discussion to make that happen automatically. Further, there are
various ways to do that. Seems at most a problem with how it is integrated in
your distribution.

~~~
fmoralesc
You don't even need to pause PA. See, for example, what cadence[^1] does to
bridge PA and Jack.

[1]:
[http://kxstudio.sourceforge.net/Applications:Cadence](http://kxstudio.sourceforge.net/Applications:Cadence)

