[Group.of.nepali.translators] [Bug 1621336] Re: snapd.boot-ok.service hangs eternally on cloud image upgrades

2018-11-03 Thread Mathew Hodson
snapd was updated in bug 1640978

** No longer affects: snapd (Ubuntu)

** No longer affects: snapd (Ubuntu Xenial)

-- 
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 cloud-init source package in Xenial:
  Fix Released

Bug description:
   Begin SRU Template [cloud-init] 
  [Impact] 
  One of cloud-init's features is to upgrade the system during first boot so 
that it is fully up to date when the user code starts running.

  [Test Case]
  launch an old instance of 16.04 that will need an update to snapd with
  user-data that indicates a package upgrade should be done.

  $ lxc image show ubuntu:74a491804877
  autoupdate: false
  properties:
aliases: 16.04,default,lts,x,xenial
architecture: amd64
description: ubuntu 16.04 LTS amd64 (release) (20160830)
label: release
os: ubuntu
release: xenial
serial: "20160830"
version: "16.04"
  public: true

  $ printf "#%s\n%s\n" cloud-config "packages: [snapd]" > user-data

  $ lxc launch ubuntu:74a491804877 xrecreate "--config=user.user-data=$(cat 
user-data)"
  $ lxc exec xrecreate -- tail -f /var/log/cloud-init-output.log

  # you will see the output log hang at:
  # Setting up snapd (2.14.2~16.04) ...

  
  ## Now get new container and patch in cloud-init
  $ lxc launch ubuntu:74a491804877 xpatched
  # let it boot, with no user-data saying to update.
  $ sleep 10

  # update the container to new cloud-init, then clean it to make
  # it look like first boot again.
  $ lxc file push - xpatched/etc/cloud/cloud.cfg.d/update.cfg < user-data
  $ lxc exec xpatched -- sh -c '
  p=/etc/apt/sources.list.d/proposed.list
  echo deb http://archive.ubuntu.com/ubuntu xenial-proposed main > "$p" &&
  apt-get update -q && apt-get -qy install cloud-init'
  $ lxc exec xpatched -- sh -c '
  cd /var/lib/cloud && for d in *; do [ "$d" = "seed" ] || rm -Rf "$d"; done
  rm -Rf /var/log/cloud-init*'

  $ lxc exec xpatched reboot
  $ lxc exec xpatched -- tail -f /var/log/cloud-init-output.log

  # snapd installed and a 'Cloud-init finished' message.

  [Regression Potential] 
  The change to running package installation later in boot will likely affect 
some things.  However, previously a larger set of things were unreliable.  This 
will make things over all more reliable.
   End SRU Template [cloud-init] 

  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/0S+   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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1621336] Re: snapd.boot-ok.service hangs eternally on cloud image upgrades

2016-09-22 Thread Launchpad Bug Tracker
This bug was fixed in the package cloud-init -
0.7.8-1-g3705bb5-0ubuntu1~16.04.1

---
cloud-init (0.7.8-1-g3705bb5-0ubuntu1~16.04.1) xenial-proposed; urgency=medium

  * New upstream release 0.7.8.
  * New upstream snapshot.
- systemd: put cloud-init.target After multi-user.target (LP: #1623868)

cloud-init (0.7.7-31-g65ace7b-0ubuntu1~16.04.2) xenial-proposed;
urgency=medium

  * debian/control: add Breaks of older versions of walinuxagent (LP:
#1623570)

cloud-init (0.7.7-31-g65ace7b-0ubuntu1~16.04.1) xenial-proposed;
urgency=medium

  * debian/control: fix missing dependency on python3-serial,
and make SmartOS datasource work.
  * debian/cloud-init.templates fix capitalisation in template so
dpkg-reconfigure works to select OpenStack. (LP: #1575727)
  * d/README.source, d/control, d/new-upstream-snapshot, d/rules: sync
with yakkety for changes due to move to git.
  * d/rules: change PYVER=python3 to PYVER=3 to adjust to upstream change.
  * debian/rules, debian/cloud-init.install: remove install file
to ensure expected files are collected into cloud-init deb.
(LP: #1615745)
  * debian/dirs: remove obsolete / unused file.
  * upstream move from bzr to git.
  * New upstream snapshot.
- Allow link type of null in network_data.json [Jon Grimm] (LP: #1621968)
- DataSourceOVF: fix user-data as base64 with python3 (LP: #1619394)
- remove obsolete .bzrignore
- systemd: Better support package and upgrade. (LP: #1576692, #1621336)
- tests: cleanup tempdirs in apt_source tests
- apt config conversion: treat empty string as not provided. (LP: #1621180)
- Fix typo in default keys for phone_home [Roland Sommer] (LP: #1607810)
- salt minion: update default pki directory for newer salt minion.
  (LP: #1609899)
- bddeb: add --release flag to specify the release in changelog.
- apt-config: allow both old and new format to be present.
  [Christian Ehrhardt] (LP: #1616831)
- python2.6: fix dict comprehension usage in _lsb_release. [Joshua Harlow]
- Add a module that can configure spacewalk. [Joshua Harlow]
- add install option for openrc [Matthew Thode]
- Generate a dummy bond name for OpenStack (LP: #1605749)
- network: fix get_interface_mac for bond slave, read_sys_net for ENOTDIR
- azure dhclient-hook cleanups
- Minor cleanups to atomic_helper and add unit tests.
- Fix Gentoo net config generation [Matthew Thode]
- distros: fix get_primary_arch method use of os.uname [Andrew Jorgensen]
- Apt: add new apt configuration format [Christian Ehrhardt]
- Get Azure endpoint server from DHCP client [Brent Baude]
- DigitalOcean: use the v1.json endpoint [Ben Howard]
- MAAS: add vendor-data support (LP: #1612313)
- Upgrade to a configobj package new enough to work [Joshua Harlow]
- ConfigDrive: recognize 'tap' as a link type. (LP: #1610784)
- NoCloud: fix bug providing network-interfaces via meta-data.
  (LP: 1577982)
- Add distro tags on config modules that should have it [Joshua Harlow]
- ChangeLog: update changelog for previous commit.
- add ntp config module [Ryan Harper]
- SmartOS: more improvements for network configuration
- tools/read-version: update to address change in version
- make-tarball: older versions of git with --format=tar.
- read-version: do not attempt git-describe if no git.
- Newer requests have strong type validation [Joshua Harlow]
- For upstream snapshot versions do not modify git-describe output.
- adjust signal_handler for version changes.
- revert unintended change to ubuntu sources list
- drop modification of version during make-tarball, tools changes.
- adjust tools and version information.
- Update build tools to work with git [Lars Kellogg-Stedman]
- fix pep8 errors in mcollective unit tests
- mcollective: add tests, cleanups and bug fix when no config in /etc.

 -- Scott Moser   Thu, 15 Sep 2016 09:57:27 -0400

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
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:
  Fix Released
Status in snapd source package in Xenial:
  In Progress

Bug description:
   Begin SRU Template [cloud-init] 
  [Impact] 
  One of cloud-init's features is to upgrade the system during first boot so 
that it is fully up to date when the user code starts running.

  [Test Case]
  launch an old instance of 16.04 that will need an update to snapd with
  user-data that indicates a package upgrade should be done.

  $ lxc image show ubuntu:74a491804877

[Group.of.nepali.translators] [Bug 1621336] Re: snapd.boot-ok.service hangs eternally on cloud image upgrades

2016-09-12 Thread Scott Moser
** 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/0S+   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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp