[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: I'm not a huge fan of systemd

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


Attachment: pgpbPVqhOKLWg.pgp
Description: PGP signature

Reply to: