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 14 $ ls /etc/init.d/* | wc -l 45 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 andevent 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 itself (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 appear before they make their own services available. And later during operation, removal of the flag should cause dependent daemons to withdraw their services.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 fileand start/stop daemons, let's call that the init service. Both systemdand 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 asthe semaphore. If the service provides its functionality over anetwork, it should be considered ready when it listens on a socket. Ifthe service provides its functionality over dbus, it should beconsidered ready when it acquires a name on the bus. Both systemd andupstart 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? 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 (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?). Indeed, it's not systemd's fault if those applications depends on it. But it's a part of the noise around systemd.