Status of upstart in Debian?

Scott James Remnant scott at
Tue Apr 6 14:29:42 UTC 2010

On Tue, 2010-04-06 at 15:58 +0200, Michael Biebl wrote:

> The problem here is, how a mixed system would work.
Let's not over-complicate the issue!

If we try and solve world peace and hunger before we start, we'll never
get anyway.

Our first priority should be allowing users to switch between using
upstart and sysvinit, this requires that sysvinit no longer be

The sysvinit maintainer has laid down what he'd like to see before
removing that field, so that's all we should concentrate on

> Open questions:
> 1/ Would we still need compat symlinks for rsyslog/dbus in /etc/rc?.d/
> for insserv to work?

> 2/ How do we ensure the correct ordering? Take the dbus/rsyslog example
> again. When can we start the legacy sysv rc2 stage and be sure that the
> upstart jobs are up?
The headers in the Upstart job provide the "alternate ordering" based on

> 3/ How do we get the LSB header information from an upstart job?

> a) Add the LSB header to the upstart *.conf file (they are comments
> after all) and let "lsb-header" simply output that. If no LSB header is
> defined, output a standard LSB header like:
> Provides: <upstart job name>
> Requires: $syslog, $remote_fs
> Default-Start: 2 3 4 5
> Default-Stop: 0 6

> b) Try to infer the LSB header information from what is encoded in
> upstart's native start on, stop on (runlevel) information. What about
> upstart jobs, that react on special events where there is no sysvinit
> equivalent, like hardware/network events?

> >  - a system with sysvinit installed would use insserv to run both init
> >    scripts and Upstart jobs (via upstart-job)
> How do we implement the "status" and "stop" action for services, i.e.
> how do we get the pid?
Write a pid file.

> Also, there are certain types of upstart jobs, which can't be handled by
> upstart-job. It's basically the "rcS" stage in a fully upstartified boot
> process where we can't rely on upstart-job but  we probably need to keep
> that kind of functionality as legacy sysvinit scripts. For that we will
> have to split that functionality from the "initscripts" package into a
> separate one.
Or have alternate packages, one for Upstart, one for sysvinit - this is
FUTURE PLANNING though; we don't need that to drop Essential: yes from

> The other remaining requirements I can remember, which Petter had and we
> discussed during the sprint in London [1], was the inittab handling.
Ah yes, of course.

> P.S: I apologize that things have been moving so slow. Please consider
> this as a request for help.
I will be attending Debconf, my priority there will be to get this
finished and uploaded with the help of any DDs in attendance.

Scott James Remnant
scott at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the initscripts-ng-devel mailing list