Discuss how Session Inits (upstart) could be migrated to systemd
Upstart is currently used to manage users graphical sessions [1], both on desktop systems [2] and on Ubuntu Touch.
= Scope =
This blueprint is to discuss:
a) How the current Session Init architecture could be made to work should PID 1 be systemd rather than Upstart.
b) Whether systemd provides some sort of compatible framework.
c) Whether the current architecture should be switched to a systemd equivalent (if available).
= Current Architecture =
When the user logs in graphically, Upstart is run in session mode ('/sbin/init --user') for that user. In session mode, the Upstart Session Init runs as that user. Multiple sessions may be created per user in this way. Note that although running a Session Init does not predicate running upstart as PID 1, the current architecture allows Session Inits access to system-level events which are proxied to all sessions via the upstart-
Further, facilities have been built upon Upstart running as a Session Init, most notably upstart-app-launch [4] which allows multiple instances of applications to be run on Touch in an apparmor-contained environment.
= Issues =
* Do we wish to retain the Upstart Session Init even when PID 1 is systemd?
* Need to understand how systemd's user session mode interfaces with PID 1 to find a strategy to replace the upstart-
* Need to find a way to replace the upstart-
* Impact on upstart-app-launch?
= References =
[1] - https:/
[2] - Run 'cat /etc/upstart-
[3] - http://
[4] - From the upstart-
Blueprint information
- Status:
- Not started
- Approver:
- Steve Langasek
- Priority:
- Undefined
- Drafter:
- James Hunt
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Review
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
= Discussion =
* does systemd run on Android kernels?
* stgraber says yes
* systemd and upstart user sessions can be available on the system in parallel, and switched between at runtime much more easily than switching between system inits (launch a guest session etc., no need to reboot). Does this mean we can do an all-at-once conversion, instead of running systemd and upstart session inits in parallel?
* switching will affect Unity's app life cycle management, which is not just a trivial job -> unit conversion (Jamie says ~ 10 lines of code for the AppArmor bits); there's even preliminary patches for systemd to do that, unknown if they already DTRT
* we have few enough jobs that this can be handled as an all-or-nothing conversion, and thus don't need to invest time trying to run both in parallel
* decouple kdbus transition from the session init discussion; kdbus is still a tech preview and far from production ready
Work Items
Dependency tree
* Blueprints in grey have been implemented.
