The code for this is in https://git.launchpad.net/~ubuntu-core-dev/+git
/systemd-trusty (I started with an import of the current trusty
version). A corresponding package is in
https://launchpad.net/~pitti/+archive/ubuntu/systemd .
This still does not match all the requirements from above: while it
removes all *.services that systemd ships by itself, there are a lot of
packages in trusty which ship their own, and these services are
currently started by the deputy systemd (Examples: dbus.service,
haveged.service, systemd-udevd.service) -- some of them fail on port
conflicts, but some others cause a second process to run. This also does
not start systemd right after package installation.
** Description changed:
Rationale: For backporting snapd to 14.04 LTS, we need to provide
systemd's service manager (not just logind and auxiliary services like
logind or timesyncd). upstart will continue to do the actual booting,
and systemd will act as a "deputy init" which by default does not ship
with/start any services by itself. We will only support this on server
(at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so
existing systems are unaffected (provided that we ensure that the other
binary packages do not change and there are no code changes that affect
processes other than the "deputy pid 1" service manager). So for plain
upgrades the regression potential is very low. However, there is a
medium potential for breakage when actually installing the new systemd
package, as it might interfere with upstart jobs or other running
processes, cause boot/shutdown hangs, etc.
Test plan:
- 1. Dist-upgrade a trusty installation to the proposed versions. Ensure this
does not pull in "systemd", and that booting, shutdown, desktop startup,
suspend on lid close, resume, logout, and user switching all still work.
+ 1. Dist-upgrade a trusty installation to the proposed versions. Ensure this
does not pull in "systemd", and that booting, shutdown, desktop startup,
suspend on lid close, resume, logout, and user switching all still work.
- 2. Install the "systemd" binary package (this will replace/remove
+ 2. Install the "systemd" binary package (this will replace/remove
systemd-shim). Verify that you can talk to the service manager with
"sudo systemctl status". Check that booting and shutdown continues to
work without (significant) delays.
- 3. Install a package that ships a systemd .service file, such as
+ 3. Ensure that "sudo journalctl" works and that "sudo systemctl status
+ systemd-journald" is running and has a few lines of log at the end
+ (unlike what you get when you run systemctl as user).
+
+ 4. Install a package that ships a systemd .service file, such as
"haveged". Ensure that the service file is ignored, "pgrep -af haveged"
should only have *one* process and "systemctl status haveged" should not
be running (it should not exist, or not be enabled and be inactive).
- 4. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure
+The only services that are running are expected to be systemd-
+ journald.service and systemd-journald.socket.
+
+ 5. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure
you can install a snap, and its services start after installing the snap
and after rebooting.
- 5. Dist-upgrade to 16.04 to ensure that there are no file conflicts,
+ 6. Dist-upgrade to 16.04 to ensure that there are no file conflicts,
dependency issues, etc.
** Also affects: systemd (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu)
Status: New => Invalid
** Changed in: systemd (Ubuntu Trusty)
Status: New => Confirmed
** Changed in: systemd (Ubuntu Trusty)
Status: Confirmed => Triaged
** Changed in: systemd (Ubuntu Trusty)
Assignee: (unassigned) => Martin Pitt (pitti)
** Changed in: systemd (Ubuntu Trusty)
Importance: Undecided => High
** Description changed:
Rationale: For backporting snapd to 14.04 LTS, we need to provide
systemd's service manager (not just logind and auxiliary services like
logind or timesyncd). upstart will continue to do the actual booting,
and systemd will act as a "deputy init" which by default does not ship
with/start any services by itself. We will only support this on server
(at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so
existing systems are unaffected (provided that we ensure that the other
binary packages do not change and there are no code changes that affect
processes other than the "deputy pid 1" service manager). So for plain
upgrades the regression potential is very low. However, there is a
medium potential for breakage when actually installing the new systemd
package, as it might interfere with upstart jobs or other running
processes, cause
