Comment 6 for bug 530779

The way strace does it should work. I don't recall the mechanism, but it
shouldn't be too hard to use. Maybe the rewrite in question is in that
direction, dunno.

On Wed, Sep 1, 2010 at 6:34 AM, Scott James Remnant <email address hidden>wrote:

> This and bug #406397 are fundamental due to Upstart's use of ptrace()
> for fork following - a rewrite of Upstart is in progress which uses
> other newer kernel mechanisms to follow forks and would not be
> vulnerable to this kind of issue. However there's no "quick fix" to it,
> and no way to backport that code.
>
> --
> init: does not wait for parent to exit when following forks
> https://bugs.launchpad.net/bugs/530779
> You received this bug notification because you are a member of Goobuntu
> Team, which is a subscriber of a duplicate bug (533059).
>
> Status in Upstart: Triaged
>
> Bug description:
> When following a fork, once Upstart receives the new pid, it immediately
> starts following that and forgets about the parent entirely not even waiting
> for it to exit.
>
> There are two problems with this:
>
> The first is the kind of daemon that forks early, but then maintains
> communication with the parent so that the parent can exit with an
> appropriate exit code in case of error (rather than the kind which only fork
> once they are ready). These kinds aren't ready until the parent exits, not
> at the point of the fork. Since upstart follows the fork, it will think
> they are ready "too early"
>
> The second is simply any that writes a pid file (which is perhaps a
> simplification of the above), if they write the pid file in the parent (as
> even nih_main_daemonise does!) then there's no guarantee the pid file
> actually exists when the "start" command returns.
>
> (Other than the fact we use ptrace tends to mean that the race works out in
> our favour)
>
>
>