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.
On Wed, 2011-01-12 at 16:37 +0000, Ben Hekster wrote: stop-daemon' ,
> 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-
> 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.