Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[Vim_User]

I am not asking anyone to fix anything. I am merely pointing out that systemd is not capable of doing what it is advertized to do unless the services it starts are specifically written to connect to systemd (read: introduce a dependency on systemd), either using its libraries or its DBus interfaces. Of course one could use hacks, but what would be the point of systemd in that case?

[Zan Lynx]

And isn't the whole point (or at least one of the main points) of systemd to be able to do exactly that [reliably start dependent services] without having to depend on unreliable mechanisms like PID files? I smell fail here, just my opinion.

You seem to be asking systemd to fix "unreliable mechanisms like PID files" without changing anything. "Fix it without changing anything" is never going to work.

systemd DID fix it, but had to add some new things to make it work. This is not unique to systemd. Apple OS X does many similar things.

[Zan Lynx]

I never stated that other init systems could do that or that there is not enough documentation. The whole point of my statement is that systemd is not able to reliably start dependent services, as long as those services are not specifically coded against the systemd libraries or its DBus interfaces..

You can easily hack in fixes if you have problems. In my opinion none of these are the RIGHT way to fix things but you can make them work.

Use a ExecStartPost=/bin/sleep 3

Or ExecStartPost=/usr/lib/service-name/wait-for-startup

Or make a wrapper script that runs the actual service and checks for startup and call that in ExecStart.

[oleid]

Please read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/

The part about forking processes is wrong: You may specify a PID file, yes, however, it is by no means the only way systemd uses to determine the childs of a forking daemon. The children are determined by cgroups.

[Nobu]

(edit: fwiw, I know you didn't. I quoted the story you asked someone to point out flaws in, and I was referencing it in my question) If you want it to "just work" and other solutions aren't able to make it "just work", then what's wrong with doing it "the systemd way"? The fact is you are able to reliably start services with systemd if you choose to, and you aren't with other systems (unless I'm misreading your statement).

Depending on dbus, or sockets, or PID files, is not the same as depending on systemd. You can use all of the above without giving a rats ass about systemd, and systemd can simply watch for the presence of their use and activate services based on that.

[Vim_User]

So, how do the clients (or, "subsequent services") find out that the service is available normally? Is it a PID file? Does it listen on a SOCKET? How does OpenRC determine when the service is "ready"? The answer may be surprisingly similar to what you would have to do if you use systemd...but I couldn't tell you without a concrete example.

I find all of the systemd documentation and publications helpful, regardless, for my simple usecase (a "user").

I never stated that other init systems could do that or that there is not enough documentation. The whole point of my statement is that systemd is not able to reliably start dependent services, as long as those services are not specifically coded against the systemd libraries or its DBus interfaces. So to get systemd working as advertized you need to make your services dependent on systemd, otherwise it will not be able by design to do what people want it to do.

And isn't the whole point (or at least one of the main points) of systemd to be able to do exactly that without having to depend on unreliable mechanisms like PID files? I smell fail here, just my opinion.

[Nobu]

Please read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/

The whole idea of systemd's service supervision and activation system is built on being able to start services asynchronously as soon as their dependencies are met (and no sooner). However, none of the above choices actually make it possible to do this with a daemon that was not written specifically to interact with systemd!

In the case of simple, there is no way for systemd to determine when the daemon is actually active and providing the service that subsequent services may depend on. If using "socket activation" (a feature by which systemd allocates the sockets a daemon will listen on and passes them to the daemon to use), this may not matter. However, most daemons not written for systemd are not able to accept preexisting sockets, and even if they can, this might preclude some of their functionality.

So, how do the clients (or, "subsequent services") find out that the service is available normally? Is it a PID file? Does it listen on a SOCKET? How does OpenRC determine when the service is "ready"? The answer may be surprisingly similar to what you would have to do if you use systemd...but I couldn't tell you without a concrete example.

I find all of the systemd documentation and publications helpful, regardless, for my simple usecase (a "user").

[Chousuke]

Please read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/

For robustness, daemons need to be modified, no matter what the design is. Any init that wants to provide asynchronous or dependency based service startup will need something similar.

sd_notify is a light dependency (it does nothing when systemd isn't actually running, and certainly a dependency on dbus is not required) and actually implements Option 1 in that blog post. (internally, it sends a datagram to a UNIX socket, so if you really wanted to avoid linking against libsystemd, you could reimplement it yourself)

The rest of the options are there for daemons that can't be modified. In any case, systemd still handles dependencies better than sysvinit.

[Vim_User]

This is incorrect.

Please read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/

[Chousuke]

Systemd is not able to reliably start services that are dependent on each other without those services specifically being coded against systemd-libraries and/or DBus. So it is a fail by design, unless you make yourself dependent on those technologies.

This is incorrect.