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 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
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 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?
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