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 <lo...@ubuntu.com> 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 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:
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
--
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
