Thank you! I should've responded but your earlier explanation did make
sense so I was thinking of just adjusting the value you mentioned and
didn't respond.
Still I believe the fix will be useful to many. Essentially we do
quarterly patching, unless there's an urgent security need, so there
The following fix should speed up u-u where originally it tried to adjust a lot
of packages:
https://github.com/mvo5/unattended-upgrades/pull/231
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
** Changed in: unattended-upgrades (Ubuntu)
Status: Invalid => 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/1843099
Title:
Unattended
In #10 the log shows that unattended-upgrades is asked to stop after 30
seconds and this is expected with the default configuration, when the
configuration is changed only to enable InstallOnShutdown.
Please note that the behaviour of unattended-upgrades changed as
described in the NEWS file.
$
** Changed in: unattended-upgrades (Ubuntu)
Status: Incomplete => Confirmed
--
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/1843099
Title:
Unattended
Using reboot did more of the same. At this point the Xenial version is
16.04.4 - we have a snapshot from 2019-05-28. unattended-upgrades was
at 0.90ubuntu0.9 but salt config management upgrades to
1.1ubuntu1.18.04.7~16.04.3 once the machine has salt installed. We
pretty much update a symlink
It went further but still failed to update - here it is via the dbus
shutdown command you supplied:
### unattended-upgrades.log:
2019-09-13 14:09:43,981 INFO Initial blacklisted packages:
2019-09-13 14:09:43,982 INFO Initial whitelisted packages:
2019-09-13 14:09:43,982 INFO Starting unattended
I'll give it a shot and report back. However the code in u-s-s is
checking against a FD as if it's an errval or retval and so if it's >0,
it bails when it's a legit FD.
Either way - I'll try to do this tomorrow and report back.
--
You received this bug notification because you are a member of
@cimmerian Could you please try using the commands I listed instead?
You probably hit https://github.com/systemd/systemd/issues/949
** Bug watch added: github.com/systemd/systemd/issues #949
https://github.com/systemd/systemd/issues/949
--
You received this bug notification because you are a
These are all VMWare VM servers but the few physicals we have ran into
the same issue.
We just use /sbin/shutdown or /sbin/reboot.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
Err, basically I meant to say we do it from the command line but we just
use shutdown or reboot.
--
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/1843099
Title:
... or this one for reboot?:
sudo dbus-send --system --print-reply --dest=org.freedesktop.login1
/org/freedesktop/login1 org.freedesktop.login1.Manager.Reboot boolean:false
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
How do you shutdown the systemd?
Do you start it from the desktop or via CLI?
If via CLI do you use this command?:
dbus-send --system --print-reply --dest=org.freedesktop.login1
/org/freedesktop/login1 org.freedesktop.login1.Manager.PowerOff boolean:false
** Changed in: unattended-upgrades
I'd submit a patch but I don't know which way we want to go with this
and ya'll are official devs. Update code to handle returned FD or just
check to see if it's not -1 or update to use apt_pkg.FileLock? Not
Sure, either way - enjoy!
--
You received this bug notification because you are a
Hello,
I looked deeper into this, I feel the issue may be with
apt_pkg.get_lock's return value now. It seems the code considers 0
success whereas now an FD is returned which seems to mean it's fine.
# Example logging output
2019-09-06 10:54:31,249 WARNING - SIGTERM or SIGHUP received, stopping
I did want to suggest, before (i.e. Bug #1806487) it seemed to be a race
/ ordering issue, could a possible fix just be adjusting the systemd
unit files after or before bits?
Although even after restarting while the system was up, a reboot didn't
work so not sure it's that simple.
--
You
16 matches
Mail list logo
