How does a post-start script know the main script has died?

Sandeep Puddupakkam (spuddupa) spuddupa at
Fri Dec 11 20:04:12 GMT 2009

Would using inotifywait with a timeout and wait for dbus-daemon to
create the pid file work? 
dbus-daemon by default creates the pid in /var/run/ (I
believe this path is configurable when launching dbus-daemon)
This may not work if dbus-daemon is crashing after the pid file is

-----Original Message-----
From: upstart-devel-bounces at
[mailto:upstart-devel-bounces at] On Behalf Of
upstart at
Sent: Wednesday, December 09, 2009 1:41 PM
To: upstart-devel at
Subject: How does a post-start script know the main script has died?

I'm launching dbus via an upstart job.  To prevent later jobs from
being launched before the daemon is ready to handle connection
requests I have a post-start script that polls for the existance of
dbus-daemon's unix domain socket in /proc/net/tcp, breaking out of a
loop when the socket appears.  When this works jobs that 'start on
started dbus' don't spawn until the socket is available.

But when dbus-daemon crashes, the post-start script runs forever.
(No, I can't just respawn dbus, but doing so doesn't seem to fix the
problem.)  I'd like the post-start script to detect that dbus has
died.  I can grep for the string 'stop' in the output of 'initcdl list
dbus' but that's gross: is there a better way?  Am I misunderstanding
upstart to think that it should kill or at least signal the post-start
script itself in this case?

We're running 0.3.8, BTW.  Our build system with its ancient autoconf
can't handle anything newer.


* From the desktop of: Eric House, eehouse at
*       Crosswords 4.4 for WinMobile plays over the internet:  *

upstart-devel mailing list
upstart-devel at
Modify settings or unsubscribe at:

More information about the upstart-devel mailing list