Status of upstart in Debian?

Tue Apr 6 13:58:27 UTC 2010

Am 06.04.2010 14:11, schrieb Scott James Remnant:
> On Mon, 2010-03-29 at 08:13 +0200, Petter Reinholdtsen wrote:
> 
>> [Michael Goetze]
>>> Hi folks,
>>>
>>> there was a flurry of activity on this list in November about
>>> migrating to upstart, but things have been very quiet since then. Is
>>> anyone actually working on this for squeeze? Is anyone planning to
>>> work on it for squeeze+1?
>>
>> There is as far as I know, no work being done.  The blocking part is
>> to implement /lib/init/upstart-job, which would allow packages to
>> migrate from init.d scripts to upstart jobs without breaking existing
>> sysvinit based installations.
>>
>> The insserv part of this is implemented (see #547235), but the upstart
>> part is not.
>>
>> Without this part in place, I believe the migration will not happen.
>>
>> The plans to implement /lib/init/upstart-job have not been followed
>> up, and I suspect someone else need to take over this task for it to
>> get done.  At the moment, Squeeze+1 seem to be the most likely target
>> for this migration, assuming we get the upstart-job implementation
>> ready in time.
>>
> Just for the purposes of clarification, my understanding of the missing
> pieces is that:
> 
>  - there should be a /lib/init/upstart-job binary
> 
>  - for compatibility with systems that retain sysvinit, symlinks to this
>    binary are placed in /etc/init.d with "old init script names"
> 
>  - upstart-job is called via these symlinks, or with an upstart job or
>    init script name as the first argument
> 
>  - the next argument is a standard "start", "stop", "restart", "reload"
>    or "force-reload" argument
> 
>  - upstart-job will run the appropriate action by using the
>    matching /etc/init/*.conf as a template, as if Upstart were
> 
> 
> The two thing I don't have in my notes are insserv related
> 
>  - how does insserv query upstart-job for the dependencies, etc. of the
>    job (for when being run from sysvinit)
> 
>  - how do we run insserv, skipping upstart jobs (for when being run from
>    upstart)
> 
> What have you implemented here?
> 
> 
> Assuming that this upstart-job binary is in place with the agreed
> functionality, I understand that you are happy for the Essential tags of
> sysvinit to be dropped - and Upstart to exist as a bona fide replacement
> for it.
> 
> This would mean:
> 
>  - a system with Upstart installed would parse and run Upstart jobs
>    natively, and use insserv to run other init scripts

The problem here is, how a mixed system would work.
Say, we already have converted dbus or rsyslog to native upstart jobs,
and a legacy sysv init script which declares a dependency
(Should-Start/Required-Start) in its LSB header.

The idea afaicr was, that insserv would utilize upstart-job to get the
LSB header information via the "lsb-header" argument.
So, for an init script /etc/init.d/<service> which points to
/lib/init/upstart-job, insserv would run "/etc/init.d/<service>
lsb-header", which would output the LSB header information on stdout.

Open questions:
1/ Would we still need compat symlinks for rsyslog/dbus in /etc/rc?.d/
for insserv to work?
If we don't install those compat symlinks and someone decides to
deinstall upstart and install sysvinit, should the sysvinit
maintainer-scripts reinstall those symlinks?
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?
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?

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.

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

In Ubuntu the /etc/inittab issue was handled by a one-time conversion in
postinst. Petter wanted a smoother upgrade path and give admins one
release cycle where /etc/inittab still was the primary source for
configuration. After one release cycle, those compat bits would be removed.

Basically what we wanted to do was:
1/ When we install upstart, check against a list of md5sums if
/etc/inittab is pristine or not. If unmodified, simply remove the file.
We'd need such a list of md5sums for the last Debian releases (and
architectures). Petter, can you get such a list for me?

2/ If /etc/inittab was modified, convert the entries to native upstart
jobs. Whenever /etc/inittab changes, the upstart jobs need to be
regenerated.
An idea we discussed, was to store those generated upstart job files in
a tmpfs like /lib/init/rw.
This also means, that we need to generate them on each boot.
This also requires changes to upstart itself, which would need support
to read upstart job files from different locations (and prioritise one
over the over, say there is tty1.conf in /lib/init/rw and /etc/init/)

I have an alternate suggestion: Generate the upstart job files from
/etc/inittab, store them in /etc/init/ *and* keep a state file, where we
store the md5sums of /etc/inittab and the generated upstart job files.
During boot, if /etc/inittab has not been modified, we can simply skip
the conversion process -> faster
If /etc/inittab has been modified, we check the md5sums of the generated
upstart job files and only update them, if they haven't been changed ->
we preserve admin changes to the upstart job files
If /etc/inittab has been modified and the upstart job files are
pristine, we update them.

I would not only run this conversion process during boot, but also when
the admin runs telinit q.

Does this sound like an acceptable plan or is there a preference of
using the original idea of a separate tmpfs in /lib/init/rw?

So, what currently exists is a upstart-job implementation for upstart
which supports, start/stop/restart/status/reload.

Missing is:
1/ "lsb-header" support in upstart-job
2/ upstart-job implementation for sysvinit (e.g. needed currently for
kfreebsd)
3/ the /etc/inittab conversion bits.
4/ layout of the initscripts package which makes it suitable for both
upstart and legacy sysvinit.

I started working on 3/ some time ago, but got side tracked. It's
something though, which I think I could finish in time for squeeze.

For 1/, we basically need to agree, how we get the LSB header
information (implicit/explicit). If we opt for adding LSB header
information to the upstart job files, the implementation would be trivial.

For 2/ I would definitely appreciate help and it is imo the main blocker.

4/ needs help from Petter but only really makes sense if 1-3 are in place.

Cheers,
Michael

P.S: I apologize that things have been moving so slow. Please consider
this as a request for help.

[1]
https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/DebianUbuntuSprint
[2] http://git.debian.org/?p=collab-maint/upstart.git;a=summary
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/attachments/20100406/52eb75c2/attachment.pgp>