This bug was fixed in the package unattended-upgrades - 0.93.1ubuntu2

---------------
unattended-upgrades (0.93.1ubuntu2) zesty; urgency=medium

  * The systemd unit needs to be an ExecStop since it is is activated on
    shutdown. Otherwise, it will get scheduled after completion of
    the local-fs.target. In the case where /var is a separate
    filesystem, unattended-upgrade-shutdown will hang until timeout
    since /var/run is expected but no longer there (LP: #1654600)

 -- Louis Bouchard <louis.bouch...@ubuntu.com>  Thu, 02 Mar 2017
16:55:26 +0100

** Changed in: unattended-upgrades (Ubuntu)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600

Title:
  unattended-upgrade-shutdown hangs when /var is a separate filesystem

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Confirmed
Status in unattended-upgrades source package in Yakkety:
  Confirmed
Status in unattended-upgrades package in Debian:
  New

Bug description:
  The systemd unit file unattended-upgrades.service is used to stop a running 
unattended-upgrade
  process during shutdown. This unit file is running together with all 
filesystem
  unmount services.

  The unattended-upgrades service checks if the lockfile for unattended-upgrade
  (in /var/run) exists, and if it does, there is an unattended-upgrade in 
progress
  and the service will wait until it finishes (and therefore automatically wait 
at
  shutdown).

  However, if /var is a separate filesystem, it will get unmounted even though 
/var/run
  is a tmpfs that's still mounted on top of the /var/run directory in the /var 
filesystem.
  The unattended-upgrade script will fail to find lockfile, sleeps for 5 
seconds, and
  tries to check the lockfile again. After 10 minutes (the default timeout), it 
will finally
  exit and the system will continue shutdown.

  The problem is the error handling in 
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
  where it tries to lock itself:

      while True:
          res = apt_pkg.get_lock(options.lock_file)
          logging.debug("get_lock returned %i" % res)
          # exit here if there is no lock
          if res > 0:
              logging.debug("lock not taken")
              break
          lock_was_taken = True

  The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an 
error.
  File descriptors are just C file descriptors, so they are always positive 
integers.
  The code should check the result to be negative, not positive. I have 
attached a patch
  to reverse the logic.

  Additional information:

  1)
  Description:  Ubuntu 16.04.1 LTS
  Release:      16.04

  2)
  unattended-upgrades:
    Installed: 0.90ubuntu0.3
    Candidate: 0.90ubuntu0.3
    Version table:
   *** 0.90ubuntu0.3 500
          500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
          500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386 
Packages
          100 /var/lib/dpkg/status
       0.90 500
          500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
          500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
  3)
  Fast reboot
  4)
  Very slow reboot (after a 10 minutes timeout)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to