[Pkg-sysvinit-devel] Bug#660824: Bug#660824: sysvinit: Please include support for upstart in startpar

[Kel Modderman]

Hi Steve,

> Package: sysvinit
> Version: 2.88dsf-22
> Severity: wishlist
> 
> Hi there,
> 
> It seems that the discussion about this patch petered out long ago on
> pkg-sysvinit-devel
> (http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-October/005345.html),
> so it's probably time to submit a proper bug report to the BTS (especially
> since sysvinit appears to be under new maintenance).
> 
> Pursuant to bug #591791 against Debian Policy about permitting alternate
> init systems in Debian, I've prepared a patch against sysvinit which would
> make startpar aware that a given job is implemented as an upstart job
> instead of a SysV init script and that startpar should defer to upstart to
> satisfy the dependency.
> 
> This enables insserv/startpar-based dependency boot to be used for sysvinit
> in conjunction with upstart as /sbin/init and native upstart jobs as
> dependencies, and is the first step towards having upstart be genuinely
> usable on Debian.  It also rolls back the previous /lib/init/upstart-job
> approach, which never worked right with startpar due to the inability to
> express dependency information.  As a result, packages shipping upstart jobs
> should now ship real init scripts in parallel (per the policy bug
> discussion), which means some changes to debhelper are wanted before this
> goes into effect.
> 
> It does *not* allow bidirectional dependencies between upstart jobs and init
> scripts.  It's assumed that a system that runs upstart will be converted
> from the bottom up - starting with rcS.d, which more or less needs to be
> converted as a block anyway.
> 
> I've tested this patch to be regression-free on sysvinit as well as working
> with upstart, and verified that the package still builds on non-Linux Debian
> ports after applying (upstart doesn't run there anyway, so it's a simple
> #ifdef :P).  I've also taken care to avoid adding any new runtime library
> dependencies here; it would have been nice to use libdbus for talking to
> upstart, but I guess some might resist such a change. :-)

This seems like a nice approach to me and thanks for driving this forward.

> 
> The patch includes two mostly unrelated changes that warrant a mention:
> 
>  - debian/rules has been patched to pass CFLAGS from dpkg-buildflags to the
>    startpar makefile.  Not really related, but was invaluable for having a
>    proper debug build when testing.
> 
>  - The patch to startpar.c includes a change to call checkdevpts() early on.
>    this is a bugfix in its own right; unless devpts support is checked at
>    the top of the loop, tasks will be launched as "interactive", meaning
>    they won't be run in parallel.  This at least impacts the first process
>    launched, I haven't checked if it affects others.  Apparently SuSE never
>    had to deal with this bug because the runtime devpts checking code was
>    ifdef'ed out there.  In any case, I found a strange interaction between
>    interactive tasks and upstart jobs; so this fix is something of a
>    prerequisite (and may indicate a latent bug in my patch).

Good catch. SuSE mount /dev/pts in very early boot (initramfs) therefore do
not require the hack. We had to patch Debian's startpar for this though to get
away from the shell based init.d script execution concurrency which existed at
the time.

Thanks, Kel.