Public bug reported:
1) The release of Ubuntu you are using, via 'lsb_release -rd' or System ->
About Ubuntu
* Ubuntu Xenial 16.04.6 LTS
2) The version of the package you are using, via 'apt-cache policy pkgname' or
by checking in Software Center
* 1.1ubuntu1.18.04.7~16.04.3
3) What you
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
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:
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.
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
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'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
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
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
I know that, strace shows it, but as we do use LDAP and so far all other
software works fine and realizes that we are logged in, systemd goes to
dbus and determines we aren't authenticated.
Most of these would result in system calls ... actually before I type
too much, can this be moved to "dbus"
We have ldap.conf set to mode 440 as there is a sensitive password used
in our config to bind to LDAP. This works for everything else that
needs it even at the user level via normal system calls.
However from what I can tell, dbus seems to need to be able to read the
file from an strace my
In my testing, using rootbinddn and separating LDAP info and LDAP creds
to separate files with ldap.conf as 444 and ldap.secret as 400 didn't
work for dbus.
I did change the group to messagebus and that worked.
--
You received this bug notification because you are a member of Ubuntu
Touch
This is related with systemd and dbus. Possibly nsswitch, ldap and
nscd.
However dbus sees the user as not being authenticated. As such, I'm
switching this over to dbus.
We see this issue every now and then depending on what we install so I
feel there's a race condition taking place which
** Description changed:
I've seen this bug reported but almost always it is when being ran as
root. This however is only an issue when ran as a non-root user.
The root user is fine. I've come across this several times and although
it's not a major issue, the only solution I've found
I tried to use "kill -TERM 1" but that didn't work. Along with daemon-
reload and daemon-reexec, that still hasn't worked. A key difference
here compared to other similar complaints is that this is with non-root
users, as the root user it's fine. As such it's not critical, however
as there are
Public bug reported:
I've seen this bug reported but almost always it is when being ran as
root. This however is only an issue when ran as a non-root user.
The root user is fine. I've come across this several times and although
it's not a major issue, the only solution I've found is to reboot
17 matches
Mail list logo
