svscan restart problems

Bug #538642 reported by jwm
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
daemontools (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: daemontools

The way daemontools starts up, at present, is:

* init or upstart runs svscanboot
* svscanboot runs some clean up, then calls svscan, piped into readproctitle

If svscanboot dies, init will restart it as expected, though it will tend to leave an svscan instance sitting around. The svc -dx call
at the start of the boot script leaves that disconnected; the new svscan process starts up fresh subprocesses.

However, if the initial svscan process dies, it's not restarted again.

The problem seems to be that the svscanboot script is still waiting on the readproctitle child process. That should exit, according to http://cr.yp.to/daemontools/readproctitle.html when it reaches the end of the input, but even though the svscan process that was connected to it's stdin has exited, this doesn't happen.

Any idea how we can fix this?

ObVersions:

Ubuntu 9.10
daemontools 1:0.76-3ubuntu2
daemontools-run 1:0.76-3ubuntu2

Revision history for this message
jwm (jwm-angrymonkey) wrote :

This seems to do the job:

trap exit CHLD
env - PATH=$PATH svscan /etc/service 2>&1 | \
readproctitle service errors: .................................................\
...............................................................................\
...............................................................................\
...............................................................................\
...............................................................................\
................................... &
wait

The trap will exit if *any* child process exits for any reason, but the command needs to be backgrounded for a signal to bubble up.

Now, if the primary svscan process dies, svscanboot will exit and be restarted. This is also the case if the readproctitle process dies, but that's desirable, too.

Can someone with more shell clues check this over?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.