[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: I'm not a huge fan of systemd

Le 08.07.2014 16:47, Martin Read a écrit :
On 08/07/14 12:00, berenger.morel@neutralite.org wrote:

Le 08.07.2014 08:58, Kushal Kumaran a écrit :
Neal Murphy <neal.p.murphy@alum.wpi.edu> writes:

On Monday, July 07, 2014 03:49:52 PM Michael Biebl wrote:
Am 07.07.2014 21:29, schrieb Andrei POPESCU:
> To prove my point (on a laptop with LXDE and just a few services):
> $ grep sleep /etc/init.d/* | wc -l
> 27
> $ ls /etc/init.d/* | wc -l
> 75

Well, you are clearly more expert than I, beer or not, since I did not
known that init scripts had sleeps in them.

Just for the info, your regex is not accurate, you do not include
comments in it ;) but it won't change the fact that there is a problem:

$ grep sleep /etc/init.d/* | wc -l
$ ls /etc/init.d/* | wc -l

Ratio: 31.1%

That's my work computer, with probable unneeded "historical" stuff so I could probably reduce both numbers (since the start of this mail I have
removed lot of them btw).

Yup, the boot speed improvements come from doing things correctly and event based. Socket activation doesn't necessarily mean things are
delayed but simply that explicit orderings are unnecessary.

The numbers you have posted are depressing, but doing that over the
complete archive is even more so.

The last time I did an archive wide check on this was early 2014, at that time we had 1235 SysV init scripts and 1124 occurences of sleep.

Whatever happened to semaphores (flags)? Seems to me that if a daemon
is a
dependency, the second-last startup thing it should do is connect to
(since it may well be asynchronous); on success, it should run a flag
up the
pole (touch a file somewhere) to tell the world that it is up and
ready to
process requests. All of its dependents should wait for that flag to
before they make their own services available. And later during
removal of the flag should cause dependent daemons to withdraw their

How would dependent services notice the creation/deletion of the
semaphore file? Presumably you would want that code (possibly using
inotify) to be in a common program, rather than reimplemented
everywhere. Since that common program is going to watch for the file and start/stop daemons, let's call that the init service. Both systemd
and upstart can do exactly this.

But, rather than introducing a file just for this purpose, it would be better to use something essential to the functioning of the service as
the semaphore.  If the service provides its functionality over a
network, it should be considered ready when it listens on a socket. If
the service provides its functionality over dbus, it should be
considered ready when it acquires a name on the bus. Both systemd and
upstart provide mechanisms for such events as well.

Indeed, since starting programs is the exact goal of the first PID
process. Plus, stuff from systemd is far easier to understand for a
beginner (systemd beginner and sysvinit beginner, I insists on this).
This dependency managing of dependencies is another advantage of
systemd, but I'm not sure it means that other softwares should have hard
dependencies on systemd, or that things like journaling, and others
pieces of system should be related to the first process.

Journaling for example should be, imho, managed in the usual way: we use
stderr in programming, which is traditionally text. Since I'm not an
expert at all, I can only guess that PID1 have to define the various
std* streams, but if someone wants binary stuff, why not simply redirect
those streams to an different application? What would be the problem
with that?

Why should desktops and end-user applications have to depend on
systemd's parts?

The systemd suite includes logind, which is a user session management system.

Strange, I wanted to check which packages does have some dependencies and I were not able to find the one I had found few times ago. So I can not continue to find example for my arguments... and since I won't argue on something I am not expert at all without some examples, I'll give you the point :)

For mpd, for example. Ok, it's started as daemon by
default, but users can run instances of it for themselves if they want, and mpd is portable. Why should it have a hard dep on libsystemd-daemon0

Because systemd is the default Linux init system for Debian jessie,
and libsystemd-daemon0 provides useful functionality for running a
daemon on a computer that uses systemd as its init system,
(it had no dep like this previously, and I doubt mpd will stop their
support for windows or bsd... so it must be enabled by some sort of flag?).

I would expect that it is enabled by a build-time flag.
Depending on libsystemd-daemon0 does not make a program depend on
having systemd as the init system. It just means that the program can
now support the most efficient of systemd's startup mechanisms without
duplication the programmer having to duplicate
The alternative to depending on libsystemd-daemon0 is duplicating the
functionality of libsystemd-daemon0 in every daemon that wants to have
optimal behaviour on systemd systems. So, when building daemons for a
Linux distribution whose *default* , it makes sense to have
libsystemd-daemon0 as a hard dependency.

So, xorg should have a hard dependency on all drivers?
But it does not, instead, there is choice: by default, it will install all (through a meta-package which depends on all) but a user can choose the unique driver that it's hardware needs. I am speaking about xorg, but it's not the only package able to be extensible by other packages. But maybe it is because of a performance issue? (runtime loading of libraries needs more time than just being linked anyway. But from what I can read from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743941#10 it seems that it is not "just linked", since the author of that reply says that an equiv package can allow to remove it.)

I wonder why it would not be possible with init systems? This would provide choice for people, while enforcing the default choice for new installations when people installing does not know about other choices (or prefer the default one).

Reply to: