[Bug 1616422] Re: [trusty SRU/FFE] Add systemd binary package for snapd

[Martin Pitt]

Status update:

> linked units from /etc/systemd/system are still being read. This needs
a bigger hammer.

Fixed in git.

> reboot is hanging

This was due to /lib/lsb/init-functions.d/40-systemd which diverted SysV
init scripts to systemctl which then ignored those as we want to disable
SysV support for deputy systemd. Fixed in git.

> I haven't tested dist-upgrade to 16.04 yet.

Done now. It mostly works except for a two-minute hang in grub-
common.postinst when trying to start grub-common.service. This gets into
a deadlock due to the LSB hook reappearing while the deputy systemd is
still running, and after the timeout grub-common is in a failed state.
What works is to manually do "sudo initctl stop systemd; sudo rm -r
/run/systemd/system; sudo apt-get -f install". After the dist-upgrade
you need to run "sudo reboot -f".

I updated https://launchpad.net/~pitti/+archive/ubuntu/systemd to
systemd 204-5ubuntu20.19pitti3 with the recent fixes, and this should
now work reasonably well except for upgrades. Please test with snapd!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1616422

Title:
  [trusty SRU/FFE] Add systemd binary package for snapd

Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Trusty:
  In Progress

Bug description:
  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.

   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. 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).

     The only services that are running are expected to be systemd-
  journald.service and systemd-journald.socket.

   5. Ensure that the standard targets are active, as that is where
  third-party/snap services hook into:

      systemctl status sysinit.target multi-user.target default.target

   6. 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.

   7. Run "sudo apt-get install --reinstall systemd" to ensure that
  upgrades to newer systemd trusty versions work.

   8. Dist-upgrade to 16.04 to ensure that there are no file conflicts,
  dependency issues, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1616422/+subscriptions