group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1654600@xxxxxxxxxxxxxxxxxx>]

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

---------------
unattended-upgrades (0.93.1ubuntu3) artful; 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@xxxxxxxxxx>  Mon, 24 Apr 2017 14:07:19 +0200

** Changed in: unattended-upgrades (Ubuntu)
       Status: In Progress => 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:
  Triaged
Status in unattended-upgrades source package in Yakkety:
  Triaged
Status in unattended-upgrades source package in Zesty:
  In Progress
Status in unattended-upgrades package in Debian:
  New

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.

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

  [Regression]
  None to be expected. A ExecStop unit will be sequenced before the Before= units which is 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