Comment 10 for bug 530779

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.