Announcement
Collapse
No announcement yet.
Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
Collapse
X
-
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?
-
Originally posted by Vim_User View PostAnd 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.
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.
Leave a comment:
-
Originally posted by Vim_User View PostI 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..
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.
Leave a comment:
-
Originally posted by Vim_User View PostPlease read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/
Leave a comment:
-
(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.Last edited by Nobu; 22 April 2014, 07:22 PM.
Leave a comment:
-
Originally posted by Nobu View PostSo, 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").
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.
Leave a comment:
-
Originally posted by Vim_User View PostPlease read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/Originally posted by ewontfixThe 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.
I find all of the systemd documentation and publications helpful, regardless, for my simple usecase (a "user").
Leave a comment:
-
Originally posted by Vim_User View PostPlease read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/
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.
Leave a comment:
-
Originally posted by Chousuke View PostThis is incorrect.
Leave a comment:
-
Originally posted by Vim_User View PostSystemd 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.
Leave a comment:
Leave a comment: