This bug was fixed in the package unattended-upgrades -
1.1ubuntu1.18.04.7~16.04.2
---
unattended-upgrades (1.1ubuntu1.18.04.7~16.04.2) xenial; urgency=medium
* Don't check blacklist too early and report updates from not allowed origins
as kept back. (LP: #1781176)
* test/test
Already verified in 0.90ubuntu0.5 for Xenial, not additional test is
needed.
** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, w
Hello Erik, or anyone else affected,
Accepted unattended-upgrades into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.7~16.04.2 in a few hours, and then
in the -proposed repository.
Please help us by testi
This bug was fixed in the package unattended-upgrades - 0.90ubuntu0.10
---
unattended-upgrades (0.90ubuntu0.10) xenial-security; urgency=medium
* No change rebuild in the -security pocket (See LP #1686470)
-- Marc Deslauriers Fri, 18 Jan 2019
13:34:27 -0500
** Changed in: unatt
** Bug watch removed: Debian Bug tracker #797108
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797108
--
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/165460
Hello Erik, or anyone else affected,
Accepted unattended-upgrades into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.7~16.04.0 in a few hours, and then
in the -proposed repository.
Please help us by testi
** Changed in: unattended-upgrades (Ubuntu Xenial)
Assignee: Louis Bouchard (louis) => (unassigned)
** Changed in: unattended-upgrades (Ubuntu Yakkety)
Assignee: Louis Bouchard (louis) => (unassigned)
** Changed in: unattended-upgrades (Ubuntu Zesty)
Assignee: Louis Bouchard (louis
This bug was fixed in the package unattended-upgrades - 0.93.1ubuntu2.1
---
unattended-upgrades (0.93.1ubuntu2.1) zesty; urgency=medium
* Complete the solution for the unattended-upgrades.service unit not
correctly working (LP: #1654600):
- d/rules : Remove the override_dh_i
This bug was fixed in the package unattended-upgrades - 0.90ubuntu0.5
---
unattended-upgrades (0.90ubuntu0.5) xenial; urgency=medium
* Complete the solution for the unattended-upgrades.service unit not
correctly working (LP: #1654600):
- d/rules : Remove the override_dh_inst
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_ins
** Changed in: unattended-upgrades (Debian)
Status: New => 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
This resolved the issue.
Version of the package testes: unattended-upgrades 0.90ubuntu0.5
Ubuntu version - 16.04 xenial
verification-done
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https:/
Test performed for verification-done for :
- Xenial
- Yakkety
- Zesty
1) Installed unattended-upgrades from -proposed
2) Verified the status of the unattended-upgrades service. All displayed :
# systemctl status unattended-upgrades
● unattended-upgrades.service - Unattended Upgrades Shutdown
** Tags removed: sts-sru-needed verification-needed
** Tags added: verification-done
--
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-u
Hello Erik, or anyone else affected,
Accepted unattended-upgrades into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/0.90ubuntu0.5 in a few hours, and then in the
-proposed repository.
Please help us by testing this new p
Hello Erik, or anyone else affected,
Accepted unattended-upgrades into yakkety-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/0.92ubuntu1.4 in a few hours, and then in the
-proposed repository.
Please help us by testing this new
Hello Erik, or anyone else affected,
Accepted unattended-upgrades into zesty-proposed. The package will build
now and be available at https://launchpad.net/ubuntu/+source/unattended-
upgrades/0.93.1ubuntu2.1 in a few hours, and then in the -proposed
repository.
Please help us by testing this new
** Description changed:
[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
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_inst
Brief update to tell everyone that I have a fix ready for all stable
releases. I will update it to Artful soon and the SRU will follow soon.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https:
Targetting Zesty as the fix will come after release so as a SRU.
** Also affects: unattended-upgrades (Ubuntu Zesty)
Importance: High
Assignee: Louis Bouchard (louis-bouchard)
Status: In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
** Tags added: sts-sru-needed
--
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 filesyste
A quick update on this issue. I have a solution ready to fix this.
Unfortunately it requires changing the WantedBy= statement, which
triggers a deb-systemd-helper bug : https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=797108
This has the effect of leaving the service disabled after upgrade. I'm
Follow-up to #34, on a system where unattended-upgrades happens to be
running when shutdown is called, the shutdown does not wait, therefore
any running dpkg is killed and the package left in an inconsistent
state.
- Xenial with single partition, InstallOnShutdown not defined.
This may be a sepa
The Unit file in #33 works for me, ie stops the 10 minute hang, when
unattended-upgrades is not running.
- Xenial with /var as a separate FS, InstallOnShutdown="false"
I will try to create a test case where unattended-upgrades is running
when shutdown is called.
--
You received this bug notific
Here is a recap of my work and current status :
#1) when a system has a separated /var, the unit will hang since it is looking
for /var/run to be present and it has been unmounted.
#2) when using Unattended-Upgrade::InstallOnShutdown "true"; the upgrade never
completes as the query to the online
Still doesn't work for me.
--
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
Here is a recap of my day of work :
The unattended-upgrades.service unit never runs the ExecStop because it
is not enabled as we see here :
# systemctl status unattended-upgrades.service
● unattended-upgrades.service - Unattended Upgrades Shutdown
Loaded: loaded (/lib/systemd/system/unattende
** Changed in: unattended-upgrades (Ubuntu)
Status: Fix Released => In Progress
** Changed in: unattended-upgrades (Ubuntu Xenial)
Status: Fix Committed => Triaged
** Changed in: unattended-upgrades (Ubuntu Yakkety)
Status: Fix Committed => Triaged
--
You received this bug
@sergei-franco:
>From what I can tell, it works for you because changing the unit the way
you did simply disable execution of the unit. When running with such a
configuration either on Xenial or Zesty, I do not see any mention of
"Unattended Upgrades Shutdown" in the console output.
When limiting
Hello!
I have changed Before to After and it is working
Here is what the unit looks like now:
[Unit]
Description=Unattended Upgrades Shutdown
DefaultDependencies=no
After=shutdown.target reboot.target halt.target network.target local-fs.target
Documentation=man:unattended-upgrade(8)
[Service
Hello,
Yes, I am fully aware that my /var/run->/run replacement in that script
is a hack.
To be clear I am not testing in Zesty but Ubuntu 16.04.2 LTS Xenial.
The setup is following:
/dev/sda1 on / type xfs (rw,relatime,attr2,inode64,noquota)
/dev/sdc on /var type xfs (rw,relatime,attr2,inode64,
@louis-bouchard
I'd love to help you, but I'm in rush on my current job.
--
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-shut
@kay-diam:
I get what you mean. I also use KVM to debug the issue.
I'm going to switch to verification-failed to this one does not get
released and push the investigation further as there is another issue
that side-tracked me :
If Unattended-Upgrade::InstallOnShutdown is set to "true", it will s
BTW, KVM allows you to use serial console you can use it for debugging.
But you have explicitly specify the order of defined "console" kernel
parameters, i.e.:
this will specify VGA console as default output:
console=ttyS0 console=tty1
this will specify serial console as default output:
console=t
@louis-bouchard
"Started Unattended Upgrades Shutdown." means that the unit was started.
Since the patch assumes that we don't use "ExecStart" this means
nothing.
Upgrade procedure should be executed on "ExecStop". But it is not
happening. I tried to set debug info inside the "ExecStop" instead o
@kay-diam
I don't understand your statement. The unit clearly get started. This is
from your log :
[ OK ] Stopped target Local File Systems.
[ OK ] Started Unattended Upgrades Shutdown. <<<
Unmounting /run/user/1000...
Unmounting /tmp...
[ OK ] Stopped Apply Kernel Variabl
@arges,
I already noticed that upgrade procedure doesn't start at all with the
new change. But actual shutdown/reboot hang has disappeared.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https:
Hello Erik, or anyone else affected,
Accepted unattended-upgrades into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/0.90ubuntu0.4 in a few hours, and then in the
-proposed repository.
Please help us by testing this new p
Before=shutdown.target reboot.target halt.target network.target local-
fs.target
should be
Before=shutdown.target reboot.target halt.target network.target
After=local-fs.target
because, AIUI, at shutdown, "Before" means "After" and "After" means
"Before".
So unattended-upgrades.service's ExecSt
Hello,
I am curious to hear about the context of your tests : my Zesty system
with a separated /var does show the problem prior to upgrade to
unattended-upgrades-0.93.1ubuntu2 and no longer hangs when the new
package is applied. There might be situations that I have not tested
where the issue coul
I have tested this and it does NOT work.
I fixed the issue in couple of different ways:
One way is completely remove the unit (who in right mind does install
updates during reboot on production servers?). I will be actively doing
that on all machines I encounter.
Another way is this:
sed -i 's#/
** Description changed:
+ [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
Tested the fix. It works. Thanks!
quick fix:
sed -i "s#ExecStart=#RemainAfterExit=yes\nExecStop=#;"
/lib/systemd/system/unattended-upgrades.service
But now it seems that it doesn't run it on shutdown. I used the
following debug service:
ExecStop=/bin/bash -c 'echo -e "\nhello###
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
** Changed in: unattended-upgrades (Ubuntu)
Status: Confirmed => In Progress
--
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-up
Bug #1661611 seems to be identical
--
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 file
As a workaround I created a symlink to /run inside the mounted /var :
mount -o bind / /mnt
ln -s /run /mnt/var/
umount /mnt
--
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.
Is there a good reason not to simply change the path to the lock file
from /var/run to /run?
--
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:
unat
** Changed in: unattended-upgrades (Debian)
Status: Unknown => New
--
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-shut
** Bug watch added: Debian Bug tracker #809669
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809669
** Also affects: unattended-upgrades (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809669
Importance: Unknown
Status: Unknown
--
You received this bug notificati
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: unattended-upgrades (Ubuntu Yakkety)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ok, here is how I understand the situation.
According to the systemd documentation about [Unit] Before= :
"Given two units with any ordering dependency between them, if one unit
is shut down and the other is started up, the shutdown is ordered before
the start-up. It doesn't matter if the orderin
You're right, I thought it was the lockfile for the shutdown helper
only.
Somewhere else in this thread I already mentioned that a dependency on
the local_fs and remote_fs targets fixes the systemd order:
Before=remote-fs.target local-fs.target
That makes sure the service is run before all file
Hello,
This logic is correct. apt_pkg.get_lock(options.lock_file) is trying to
acquire a lockfile (/var/run/unattended-upgrades.lock) which is only
possible if no unattended-upgrade is already running. If it can acquire
the lock, it means that NO unattended-upgrade is running, hence shutdown
may p
** Also affects: unattended-upgrades (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: unattended-upgrades (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Changed in: unattended-upgrades (Ubuntu)
Assignee: (unassigned) => Louis Bouchard (louis-bouch
I get this sometimes on shutdown but not always.
Erik, until the fix reaches users, should I:
systemctl disable unattended-upgrades.service
?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
http
** Changed in: unattended-upgrades (Ubuntu)
Importance: Undecided => High
--
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-s
FWIW, the init script /etc/init.d/unattended-upgrades should be
removed from systemd systems (Xenial, Yaketty).
--
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/165
I have narrowed down. This bug was introduced by the fix in #1618900.
That tries to fix the problem of the the unattended-upgrades.service
by letting it depend on network.target and local-fs.target.
However, that doesn't change any of the dependencies, it only makes
the race window larger.
After s
I have same problem. I need to kill unattended-upgrades service manually
to shutdown machine. This problem comes in 2017 year.
System is Ubuntu 16.04 x86_64.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: unattended-upgrades (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
** Tags added: patch
--
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
I have also tried to let the systemd unit file for this service WantedBy the
umount.target.
According to the systemd documentation that should make it run before the
filesystems
are unmounted, but apparently that doesn't work. systemctl list-dependencies
still shows
that the unattended-upgrade.s
64 matches
Mail list logo