Re: Custom Reload command/signal in upstart

[Clint Byrum <spamaps@debian.org>]

Excerpts from John Paul Adrian Glaubitz's message of 2013-06-01 03:52:51 -0700:
> On 06/01/2013 12:24 PM, Vincent Bernat wrote:
> > I don't know how systemd behaves in this way (so this is not something
> > to hold against upstart), but there are so many daemons that need to be
> > started after the network has been configured that it should be easy to
> > do this. For example, most daemons binding to a specific address needs
> > to be started after the address has been configured.
> 
> Which is exactly the very one design decision which is wrong in
> upstart. Starting any service as soon as all its dependencies are
> fulfilled, is putting the dependency chain upside down and doesn't
> make any sense. There is no point to start a daemon unless you actually
> need it.
> 

You might be interested to know that Upstart also has socket activation
available. For whatever reason, Upstart and systemd chose _slightly_
different interfaces for this (shame on BOTH), but they work more or
less the same. Upstart also has udev and file activation available.

Also, upstart is not dependency based, it is event based, so you are not
starting things when "dependencies are fulfilled", but at the precise
moment you have asked for.

> You want services to start when you need them, meaning you always
> keep the amount of running daemons minimal. systemd runs sshd when
> someone tries to connect to it and before running sshd, it makes sure
> all of its dependencies are running and starts them prior to starting
> sshd if necessary.

I think the usage pattern of the system dictates whether I want the
daemons all up at boot time, or on-demand. For servers, I want them all
up at boot time, using up as much RAM as they will need immediately,
so that they are not competing with buffers and cache for RAM when the
system is at its peak usage.

For a nice low power laptop, I like the idea of having as little churn
as possible with things sitting doing nothing. However, we do have that
"swap" thing for these times. I know it is crude, but it has been working
out quite well for some time now, and is something that can work without
adding code to existing daemons.