> Problem probably is in startpar-bridge. Since last mail also
samba-ad-dc service/job is affected. Both services upstart starts
properly:
Upstart starts those jobs properly *according to Upstart*. The problem
here is that startpar has a different definition of starting properly,
and a lot of different service semantics.
> But both jobs ends quickly after start what probably causes startpar
waits like this:
Exactly. binfmt-support is an apparent incompatibility. In Upstart,
binfmt-support is a task. It runs once and is considered to be
successfully run by Upstart. startpar has something different to say.
Although startpar sees that the job has been run, it ignores that part
because the job has also been stopped. So it considers the fact that
the job is last stopped to mean that services that start after
binfmt-support must not be started, when in reality, they can do so
easily.
Another situation is where the daemon detects that it is not enabled
and exits early. This is what I think is happening in samba-ad-dc.
Although the startpar started init script would do the same thing,
startpar ignores the init script's stop because that is just how
startpar works!
One of the last situations I can think of is the job stopping itself in
pre-start with `{ stop; exit 0; }`. This one is similar to sysv init
scripts because they also do checks to see if they are enabled, or the
package is still installed. However, the Upstart job and sysv init
script are still quite different. After the script detects the package
is installed, it exits 0, and the boot proceeds. On the other hand, the
Upstart job explicitly stops, and startpar gets the stopped event from
the startpar-bridge.
Essentially, the startpar-bridge needs to take more liberties with what
it tells startpar. If startpar wants the job to be started, and the job
starts then stops quickly (binfmt-support, samba-ad-dc), the
startpar-bridge should ensure that the stopped event does not stop
startpar from continuing. Likewise, jobs that try to start, but stop
halfway (before they are done forking, or in pre-start), should also
not hold up startpar.
Most importantly, the startpar-bridge needs to remember these early
stopped jobs and feed the stopped event to startpar on shutdown.
Steve, could you give your thoughts on how to go about improving this
situation? Furthermore, could you point me to the
startpar-upstart-inject source code? I could not find it in Upstart's
or sysvinit util's source trees.
Best regards,
--
Cameron Norman
