group.of.nepali.translators team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: snapd (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Changed in: snapd (Ubuntu Xenial)
       Status: New => In Progress

** Changed in: snapd (Ubuntu Xenial)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1621336

Title:
  snapd.boot-ok.service hangs eternally on cloud image upgrades

Status in cloud-init package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Triaged
Status in cloud-init source package in Xenial:
  New
Status in snapd source package in Xenial:
  In Progress

Bug description:
  I reproducibly run into an eternal hang when deploying services with
  Juju, when it prepares a new xenial testbed. The current xenial cloud
  image does not have the latest snapd, so snapd gets dist-upgraded:

  Preparing to unpack .../snapd_2.14.2~16.04_amd64.deb ...
  Warning: Stopping snapd.service, but it can still be activated by:
    snapd.socket
  Unpacking snapd (2.14.2~16.04) over (2.13) ...
  Setting up snapd (2.14.2~16.04) ...
  [...] hangs

  The postinst tries to start snapd.boot-ok.service on upgrade:

             |-cloud-init(311)-+-apt-get(577)---dpkg(845)---snapd.postinst(846)---perl(919)---systemctl(922)
             |                 `-sh(354)---tee(355)

  root       922  0.0  0.0  25316  1412 pts/0    S+   06:09   0:00
  /bin/systemctl start snapd.boot-ok.service

  This hangs eternally because:

   - cloud-init's dist-upgrade runs *during* the boot process, so that
  the system is not fully booted yet when this happens (see bug
  1576692); thus multi-user.target is *not* yet active

   - snapd.boot-ok.service is After=multi-user.target

   - "systemctl start" is synchronous by default, i. e. it waits until
  the service is started unless you use --no-block.

  Thus snapd.postinst waits on snapd.boot-ok.service waits on multi-
  user.target waits on cloud-init to finish waits on snapd.postinst to
  finish.

  I think conceptually you shouldn't start snapd.boot-ok.service in the
  postinst; if the system is already booted (manual dist-upgrade) it
  should already be running, and if it does get upgraded during boot
  (with cloud-init) then you shouldn't pretend that booting is already
  finished. So I suggest to use dh_installinit with --no-scripts for
  snapd.boot-ok.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1621336/+subscriptions