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?