Discuss transition from upstart as PID 1 to systemd

Registered by James Hunt

Discuss the strategy for a migration from Upstart as PID 1 to systemd.

= Scope =

This discussion is limited to the system init (PID 1) only. Discussion of the implications of a migration to systemd on the current Session Init will be covered by a separate blueprint.

= Discussion Points =

* Timing - when should such a transition occur to ensure maximum system stability?
* Work closely with Debian.
* Co-installability of systemd and upstart (to simplify automated (re-)boot testing whilst preparing for the transition.
* systemd stateful re-exec support.
* Upgrade testing for upstart-as-pid1 release to systemd-as-pid1 release.
* Building and running systemd on Android kernels.
* Building and running systemd on all the Ubuntu architectures.
* Migration plan for "main": convert atleast upstart-only services to systemd units, plus associated testing.
* Migration plan for critical services in other components (mysql, etc) - need reports on all upstart-only services in other components to ensure those services continue to work after a systemd cut-over.
* dep-8 / boot / shutdown / scenario testing (encrypted LVM, multiple NFS mounts, read-only root, initramfs-less, etc) and impact on QA.
* Daily builds ([1] and [2]).
* Use systemd in the initramfs? If so, impact on porting existing initramfs-tools scripts and hooks.
* Boot speed reports - QA needs to monitor these for regressions.
* Migration guide for those porting Upstart jobs to Systemd (https://wiki.ubuntu.com/SystemdForUpstartUsers)
* Documentation on debugging systemd units / boot issues.
* Ensure current boot paths can be tested and supported by systemd:
    * graphical (plymouth).
    * text (server).
    * friendly-recovery (If still using initramfs-tools, modify /usr/share/initramfs-tools/init to invoke 'systemd --unit=recovery.target' in recovery boot path).
* Ability to run systemd in LXC containers.
* Impact of systemd on cgmanager.
* cloud-init - currently supports systemd so should be a transparent change?
* apport hook for systemd.
* SOS report hook for systemd.
* Server guide documentation.
* Access to systemd's Coverity Scan page.
* Publicise need to port less important services in components other than "main", to ensure they continue to work when the systemd-cutover occurs.

= References =


[1] - https://code.launchpad.net/~upstart-devel/+recipe/upstart-daily
[2] - https://code.launchpad.net/~canonical-foundations/+recipe/upstart-daily-nonvirt

Blueprint information

Not started
Steve Langasek
James Hunt
Needs approval
Series goal:
Accepted for utopic
Milestone target:
milestone icon ubuntu-14.10

Related branches



= Discussion =
 * there are services we have upstart jobs for that have been written since the upstart transition in Ubuntu, that have no sysvinit compatibility; those need to be transitioned to systemd units
Concern is that mixing systemd and upstart at the same time leads to more trouble (due to two inits handling jobs) than it saves compared to just converting all our system upstart jobs and then flip over
* separate boot (rcS.d) transition from actual services (rc2.d equivalents); these should be parallelizable
 * can live with an ugly boot (while transitioning plymouth integration etc.) for a while
 * running upstart as a child reaper is still required for supporting admin-defined jobs, to faciliate upgrades; we can then also use it to handle rc2.d-type jobs (except the ones that trigger on system/hardware events)
 * we have server-ish packages which have custom upstart jobs which do a lot more than the corresponding SysV script (and those are often broken)
 * Target for 16.04 LTS is to support upstart as a helper init for compatibility with locally-installed jobs
 * what do we do during the transition period to determine whether or not to run an upstart job with the "deputy pid1"? we do need to run admin-defined jobs, but not the ones which already have a corresponding systemd unit
   → trigger will iterate over upstart jobs, map them to packages, checks whether package ships systemd units; if so, create a .override in a non-conffile location which is only evaluated when running upstart as ! pid 1
     * this enables upstart as init to continue running everything, and to bypass anything that's systemdified when running under systemd
     * precondition is to vet the set of packages that currently ship both upstart jobs and systemd units and make sure the systemd units are actually equivalent

= Packages =
See http://www.piware.de/2014/04/booting-ubuntu-with-systemd-test-packages-available/ and http://www.piware.de/2014/04/booting-ubuntu-with-systemd-now-in-utopic/

Bugs: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=systemd-boot

All init.d, upstart jobs, and systemd units: http://bazaar.launchpad.net/~upstart-devel/upstart/upstart-jobs
Analysis of that, and progress: http://pad.ubuntu.com/missing-systemd-units


Work Items

Work items:
[pitti] Modify systemd to support talking to the upstart control socket for reboot command (required for smooth upgrades; bug 1370329): DONE
Try running upstart with child-reaper support under systemd as PID 1 (should "just work (TM)" - needs change to register D-Bus control server:): DONE
[pitti] provide systemd binary for experimentation (PPA for trusty, archive for utopic): DONE
[jamesodhunt] Add support to upstart for reading overrides from a separate directory (read if upstart != pid 1): DONE
Write dpkg trigger to disable upstart jobs (via above override directory) from packages which have systemd units: TODO
Make sure all packages that have both upstart jobs and systemd units provide equivalent functionality in the systemd units: TODO
Convert all of rcS.d (and upstart equivalents) to systemd units: TODO
Deep validation of systemd boot, across a variety of configurations: TODO
Flip the switch: TODO
Survey the archive and convert all other existing upstart jobs to systemd units: TODO
[pitti] set up automatic boot testing with systemd (as autopkgtest): DONE
[pitti] Validate the crucial running services (D-BUS, lightdm, etc.): DONE

Dependency tree

* Blueprints in grey have been implemented.