Re: Custom Reload command/signal in upstart
- To: debian-devel <email@example.com>
- Subject: Re: Custom Reload command/signal in upstart
- From: Clint Byrum <firstname.lastname@example.org>
- Date: Tue, 27 Aug 2013 17:50:56 -0700
- Message-id: <[🔎] email@example.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <CALjhHG-nOd7qHv-tQrJkEKsvO1m+M8He50YdhsVt84_UhbOSemail@example.com> <20130531224415.GA8976@virgil.dodds.net> <firstname.lastname@example.org>
Excerpts from Vincent Bernat's message of 2013-06-01 03:24:02 -0700:
> ❦ 1 juin 2013 00:44 CEST, Steve Langasek <email@example.com> :
> >> start on (local-filesystems and net-device-up IFACE!=lo)
> >> stop on runlevel 
> > FYI, it's strongly recommended to use 'start on runlevel ' here as the
> > start condition, for several reasons:
> > - The 'filesystem' events are one-time events seen only at boot time; if
> > the admin drops the system to runlevel 1 and then returns to runlevel 2,
> > you probably want the service to restart.
> > - The event name is 'local-filesystem', not 'local-filesystems', so this
> > job wouldn't auto-start at all. (FWIW, the 'initctl check-config'
> > command from the upstart package would warn about this; but this tool is
> > only usable when upstart is the running init, so probably not ideal for
> > packagers not running upstart themselves.)
> > - The 'local-filesystem' event may be emitted before any remote filesystems
> > have been mounted... which might include part or all of /usr and /var.
> > So since php5-fpm is itself not a service that is used for mounting
> > remote filesystems, it should not try to start until the filesystem is
> > completely up.
> > The 'runlevel' event is later than both the 'local-filesystem' event and the
> > 'net-device-up' events, except in the case where your network interface is
> > configured with network-manager instead of ifupdown. So you shouldn't need
> > to worry about this causing your service to start too "early".
> The upstart cookbook does not exactly match what you say (so, it may
> need an update):
> I had huge difficulties to get an upstart job that starts after static
> network configuration has been done. I have things like this:
> start on (static-network-up or started networking)
> start on (local-filesystems and net-device-up IFACE!=lo)
> start on (filesystem and net-device-up IFACE=vlan481)
> The first one is here to be compatible with older upstart (like the one
> in Lucid).
> It seems that now, we can do this, but the cookbook also says this is
> not here yet:
> start on started network-services
I would love to see that added, I have just never had time to kick off
the transition to have this be the standard.
Anyway, the equivalent for Ubuntu 12.04 is:
start on runlevel 
I have not tested Debian's upstart much, but I assume somebody took
the time to bring the static-network-up event from Ubuntu to Debian and
make runlevel  the appropriate choice in Debian.
On Ubuntu 10.04, you can use that too if you change
/etc/init/rc-sysinit.conf to 'start on net-device-up IFACE=xxx' where
xxx is your network interface (and if you have more, use the 'and
net-device-up IFACE=yyyy' for those).
Anyway, trying to use the raw events is a huge waste of your time. It
may work, but why become a boot expert if all you want is "start when
the system is ready"?
> 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.
runlevel  is meant to be "when the system is ready", and is what
99% of all daemons should use. Basically if you are not supporting the
march toward runlevel 2, or dependent on another daemon being up, then
you should be start on runlevel .