Comment 13 for bug 530779

Revision history for this message
Clint Byrum (clint-fewbar) wrote : Re: [Bug 530779] Re: init: does not wait for parent to exit when following forks

On Wed, 2011-01-12 at 16:37 +0000, Ben Hekster wrote:
> I'd like to add my two cents to this discussion, as it bears some
> relation to the mechanism Upstart uses to determine the PID to monitor.
>
> I was attempting to Upstart-enable PBS/TORQUE-- which is a suite of
> cluster resource management software. Because of the way it was
> packaged (not wanting to mess with the RPM specification too much), and
> to maintain maximum compatibility with the SysV version, I tried doing
> this by having the Upstart '.conf' directly invoke the SysV scripts by
> doing something like:
>
> exec /etc/init.d/pbs_mom start
>
> After struggling with this for a while I finally understood why this
> can't work. The 'pbs_mom' SysV script calls LSB 'start-stop-daemon',
> which in turn invokes the actual PBS daemon executable. In other words,
> there are *three* fork()s involved in starting the daemon-- so neither
> 'expect fork' (one fork) nor 'expect daemon' (two forks) find the right
> PID in this case.
>
> In fact, the situation is actually worse than that: the 'pbs_mom' script
> calls 'start-stop-daemon' once early on in a 'test' mode, to verify that
> the daemon isn't actually already running. So in actual fact, there are
> *five* fork()s involved in starting the daemon.
>
> It's obvious that the way Upstart is designed, it can never reliably
> support starting services in this way. The right approach is just to
> start the daemon directly, without going through intermediate SysV
> scripts.
>
> It is somewhat concerning to me, though, that there seem to be valid use
> cases and other boundary cases that cannot be supported by Upstart under
> its current design. The alternative, already proposed by others, would
> be the ability to specify the PID (or a PID file) to Upstart. The
> assumption that Upstart will always be able to 'reverse engineer' the
> daemon PID, by some clever mechanism or other, seems to me somewhat
> questionable.
>

You can absolutely use the init.d script from upstart if there is a need
to depend on upstart events to time the startup:

-----------

# start-pbs

start on upstart-event-to-start-on

task

exec /etc/init.d/pbs start

-----------

# stop-pbs

start on upstart-event-to-stop-on

task

exec /etc/init.d/pbs stop

-----------

This is a bit of a hack, but it works if the init.d script must be used.