This bug was fixed in the package unattended-upgrades - 0.92ubuntu1.4

---------------
unattended-upgrades (0.92ubuntu1.4) yakkety; urgency=medium

  * Complete the solution for the unattended-upgrades.service unit not
    correctly working (LP: #1654600):
    - d/rules : Remove the override_dh_installinit. The stop option is no longer
      available so the command falls back to default. This is the normal
      behavior so the override is not required
    - d/unattended-upgrades.init : Add Default-Start runlevels, otherwise the
      unattended-upgrades.service unit cannot be enabled on boot
    - d/postinst : Cleanup the stop symlinks created by the wrong
      override_dh_installinit. Without that, the systemd unit cannot be
      enabled correctly.
      Force disable the service before deb-systemd-helper runs so the old
      symlink is not left dangling (workaround for Debian Bug #797108).
      Force enable and start of the systemd unit to work around Debian Bug 
#797108
      which fails to enable systemd units correctly when WantedBy= statement
      is changed which is the case here.
    - d/unattended-upgrades.service : Fix the service so it runs correctly on
      shutdown :
        Remove DefaultDependencies=no : Breaks normal shutdown dependencies
        Set After= to network.target and local-fs.target. Since our service is
        now ExecStop, it will run before network and local-fs become 
unavailable.
        Add RequiresMountsFor=/var/log /var/run /var/lib /boot : Necessary if
        /var is a separate file system. Set WantedBy= to multi-user.target
    - Add DEP8 tests to verify the following :
      Verify that the unattended-upgrades.service unit is enabled and started.
      Verify that InstallOnShutdown works when configured.

 -- Louis Bouchard <louis.bouch...@ubuntu.com>  Tue, 04 Apr 2017
18:31:42 +0200

** Changed in: unattended-upgrades (Ubuntu Yakkety)
       Status: Fix Committed => Fix Released

** Changed in: unattended-upgrades (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/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:
  Fix Released
Status in unattended-upgrades source package in Yakkety:
  Fix Released
Status in unattended-upgrades source package in Zesty:
  Fix Released
Status in unattended-upgrades package in Debian:
  Fix Released

Bug description:
  [SRU justification]
  This fix is needed to make sure that the system does not hang on shutdown 
when /var is a speparate file system

  [Impact]
  System can hang up to 10 minutes if not fixed.

  [Fix]
  Change the systemd unit's ExecStart to an ExecStop so the unit is correctly 
sequenced.
  Change WantedBy to multi-user.target. This requires working around Debian Bug 
#797108 which causes the new unit not to be enabled.
  Remove the unneeded override_dh_isntallinit
  Add Default-Start levels to the SysV initscript
  Improve DEP8 testing

  [Test Case]
  In a VM with /var separated from the / file system, shutdown the VM. It will 
hang for 10 minutes

  [Regression]
  Upgrade has been tested on Xenial, Yakkety, Zesty. do-release-upgrade has 
been tested from Trusty to Xenial. All behave as expected.

  A change of behavior may occur now that the systemd unit is correctly
  enabled, which would make functionalities like InstallOnShutdown to
  work as expected whereas it could have been broken previously. This
  cannot be considered as a regression as it is expected behavior.

  Shutdown may be slowed down as it now correctly depends on /var and
  /boot to be available so the unit will run earlier than previously.

  [Original description of the problem]
  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/~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

Reply via email to