[Bug 1928744] Re: Disk IO very slow on kernel 4.15.0-142-generic
This bug is also affecting us. We're on Xenial but use this kernel for HWE. Basically for our monitoring, the leader to all this shows as dirty memory and or filesystem writeback. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928744 Title: Disk IO very slow on kernel 4.15.0-142-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928744/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885948] Re: systemd 229 / dbus 1.10.6-1ubuntu3.5 (16.04) and systemd 237 / dbus 1.12.2-1ubuntu1.1 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885948 Title: systemd 229 / dbus 1.10.6-1ubuntu3.5 (16.04) and systemd 237 / dbus 1.12.2-1ubuntu1.1 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1885948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885948] Re: systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user
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 co-workers ran. In all my tests I didn't see it go to strace, and this was prior to specifying the network, however in their test run, they say an access denied for /etc/ldap.conf. Just now I ran a test where I chmod'd it to be 444, and then ran systemctl as a normal user, it worked. My co-workers ran an strace against the dbus process and saw it was trying to read /etc/ldap.conf. I'm not sure why it would need that versus just using syscalls. Anyway, it worked. So then I changed it back, changed into a different user, it still worked. Then I tried to invalidate nscd cache, it still worked. So I feel depending on what starts and or restarts where, it's a draw as to whether or not it'll work. I'm checking to see if dbus caches LDAP creds but also going to try and separate ldap.conf creds to another file. Thank you! ** Summary changed: - systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user + systemd 229 / dbus 1.10.6-1ubuntu3.5 (16.04) and systemd 237 / dbus 1.12.2-1ubuntu1.1 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885948 Title: systemd 229 / dbus 1.10.6-1ubuntu3.5 (16.04) and systemd 237 / dbus 1.12.2-1ubuntu1.1 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1885948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885948] Re: systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user
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 affects the order. I'll put more details below, hopefully we can at least advise others on this particular scenario if it's not a bug, however as systemd has before, after methods, perhaps we can refine the unit files? ** Package changed: systemd (Ubuntu) => dbus (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885948 Title: systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1885948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885948] Re: systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user
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" then? I can move it if possible, I just wanted to get a conversation going and felt that since systemd, dbus, etc are under freedesktop it may be related and I don't directly use dbus, but I do use systemd :-) Thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885948 Title: systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1885948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885948] Re: systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user
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 some services / units that can be used by users, it may be an issue for others as sometimes a reboot can't be done. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885948 Title: systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1885948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885948] Re: systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user
** 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 is to reboot the
system.
I see this when running strace, tracing the network.
We recently installed docker-ce and updated our version of salt from
2016.8.3 using python 2 to 2019.2.4 using python 3.
### 16.04 - systemd 229 on d1lmonitoringdev1 ###
## non-root user ##
$ strace -f -s 16384 -e trace=network systemctl status ntp
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation
not permitted)
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation
not permitted)
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/dbus/system_bus_socket"},
33) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
getsockopt(3, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
sendmsg(3, {msg_name(0)=NULL, msg_iov(3)=[{"\0AUTH EXTERNAL ", 15},
{"3130313631", 10}, {"\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", 28}],
msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 53
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"REJECTED EXTERNAL
DBUS_COOKIE_SHA1 ANONYMOUS\r\nERROR \"Need to authenticate first\"\r\n", 256}],
msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 82
strace: Process 29413 attached
[pid 29413] --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=29412,
si_uid=10161} ---
Failed to get properties: Access denied
[pid 29413] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=29413,
si_uid=10161, si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 1 +++
## root user ##
# Truncated because as root it works.
$ sudo strace -f -s 16384 -e trace=network systemctl status ntp
[sudo] password for zbukhari:
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = 0
getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/private"}, 22) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
getsockopt(3, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
sendmsg(3, {msg_name(0)=NULL, msg_iov(3)=[{"\0AUTH EXTERNAL ", 15}, {"30",
2}, {"\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", 28}], msg_controllen=0,
msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 45
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"OK
3139491ef18e4f4c84fae863d4dd042f\r\nAGREE_UNIX_FD\r\n", 256}],
msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 52
sendmsg(3, {msg_name(0)=NULL,
msg_iov(2)=[{"l\1\4\1\5\0\0\0\1\0\0\0\237\0\0\0\1\1o\0,\0\0\0/org/freedesktop/systemd1/unit/ntp_2eservice\0\0\0\0\3\1s\0\6\0\0\
0GetAll\0\0\2\1s\0\37\0\0\0org.freedesktop.DBus.Properties\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\10\1g\0\1s\0\0",
176}, {"\0\0\0\0\0", 5}], msg_controllen=0, msg_flags=0},
MSG_DONTWAIT|MSG_NOSIGNAL) = 181
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\35
\0\0\1\0\0\0\23\0\0\0\5\1u\0\1\0\0\0", 24}], msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24
### 18.04 - systemd 237 on d1lzbbyodev1 ###
## non-root user ##
-
- $ strace -f -e trace=%network systemctl status ntp
+ $ strace -f -s 16384 -e trace=%network systemctl status ntp
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation
not permitted)
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation
not permitted)
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
connect(3, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 29) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
- getsockopt(3, SOL_SOCKET, SO_PEERSEC, 0x5586565b8450, [64]) = -1 ENOPROTOOPT
(Protocol not available)
+ getsockopt(3, SOL_SOCKET, SO_PEERSEC, 0x56338b
[Bug 1885948] [NEW] systemd 229 (16.04) and 237 (18.04) error with "Failed to get properties: Access denied" when ran as non-root user
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 the
system.
I see this when running strace, tracing the network.
We recently installed docker-ce and updated our version of salt from
2016.8.3 using python 2 to 2019.2.4 using python 3.
### 16.04 - systemd 229 on d1lmonitoringdev1 ###
## non-root user ##
$ strace -f -s 16384 -e trace=network systemctl status ntp
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation
not permitted)
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation
not permitted)
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/dbus/system_bus_socket"},
33) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
getsockopt(3, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
sendmsg(3, {msg_name(0)=NULL, msg_iov(3)=[{"\0AUTH EXTERNAL ", 15},
{"3130313631", 10}, {"\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", 28}],
msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 53
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"REJECTED EXTERNAL DBUS_COOKIE_SHA1
ANONYMOUS\r\nERROR \"Need to authenticate first\"\r\n", 256}],
msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 82
strace: Process 29413 attached
[pid 29413] --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=29412,
si_uid=10161} ---
Failed to get properties: Access denied
[pid 29413] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=29413, si_uid=10161,
si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 1 +++
## root user ##
# Truncated because as root it works.
$ sudo strace -f -s 16384 -e trace=network systemctl status ntp
[sudo] password for zbukhari:
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = 0
getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/private"}, 22) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
getsockopt(3, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
sendmsg(3, {msg_name(0)=NULL, msg_iov(3)=[{"\0AUTH EXTERNAL ", 15}, {"30", 2},
{"\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", 28}], msg_controllen=0, msg_flags=0},
MSG_DONTWAIT|MSG_NOSIGNAL) = 45
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"OK
3139491ef18e4f4c84fae863d4dd042f\r\nAGREE_UNIX_FD\r\n", 256}],
msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 52
sendmsg(3, {msg_name(0)=NULL,
msg_iov(2)=[{"l\1\4\1\5\0\0\0\1\0\0\0\237\0\0\0\1\1o\0,\0\0\0/org/freedesktop/systemd1/unit/ntp_2eservice\0\0\0\0\3\1s\0\6\0\0\
0GetAll\0\0\2\1s\0\37\0\0\0org.freedesktop.DBus.Properties\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\10\1g\0\1s\0\0",
176}, {"\0\0\0\0\0", 5}], msg_controllen=0, msg_flags=0},
MSG_DONTWAIT|MSG_NOSIGNAL) = 181
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\35
\0\0\1\0\0\0\23\0\0\0\5\1u\0\1\0\0\0", 24}], msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24
### 18.04 - systemd 237 on d1lzbbyodev1 ###
## non-root user ##
$ strace -f -s 16384 -e trace=%network systemctl status ntp
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation
not permitted)
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation
not permitted)
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
connect(3, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 29) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
getsockopt(3, SOL_SOCKET, SO_PEERSEC, 0x56338b39b450, [64]) = -1 ENOPROTOOPT
(Protocol not available)
getsockopt(3, SOL_SOCKET, SO_PEERGROUPS, "", [256->0]) = 0
getsockopt(3, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0
getsockname(3, {sa_family=AF_UNIX}, [128->2]) = 0
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0AUTH EXTERNAL
", iov_len
[Bug 1843099] Re: Unattended upgrades does not work on shutdown
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 often are a lot of packages to update. This is in a corporate environment. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843099 Title: Unattended upgrades does not work on shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1843099] Re: Unattended upgrades does not work on shutdown
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 which has two publish dates, 2019-05-28 (old) to 2019-09-04 (new). I'm not sure if that's playing a role but I do know 0.90ubuntu0.9 worked for me last time. # As root dbus-send --system --print-reply \ --dest=org.freedesktop.login1 /org/freedesktop/login1 \ org.freedesktop.login1.Manager.PowerOff boolean:false 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843099 Title: Unattended upgrades does not work on shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1843099] Re: Unattended upgrades does not work on shutdown
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 upgrades script 2019-09-13 14:09:43,983 INFO Allowed origins are: o=Ubuntu-aptly,a=xenial 2019-09-13 14:10:01,496 INFO Packages that will be upgraded: apport apt-transport-https base-files bash bind9-host bsdutils btrfs-tools busybox-initramfs busybox-static bzip2 ca-certificates cloud-guest-utils cloud-initramfs-copymods cloud-initramfs-dyn-netconf console-setup console-setup-linux curl dbus dh-python distro-info-data dns-root-data dnsmasq-base dnsutils dpkg file friendly-recovery gettext-base git git-man gnupg gpgv grub-common grub-legacy-ec2 grub-pc grub-pc-bin grub2-common hdparm ifupdown initramfs-tools initramfs-tools-bin initramfs-tools-core iproute2 isc-dhcp-client isc-dhcp-common keyboard-configuration kmod krb5-locales libapparmor-perl libapparmor1 libasprintf0v5 libbind9-140 libblkid1 libbz2-1.0 libc-bin libcurl3-gnutls libdb5.3 libdbus-1-3 libdns-export162 libdns162 libelf1 libexpat1 libfdisk1 libgcrypt20 libglib2.0-0 libglib2.0-data libgnutls-openssl27 libgnutls30 libicu55 libisc-export160 libisc160 libisccc140 libisccfg140 libk5crypto3 libkmod2 libldap-2.4-2 liblwres141 libmagic1 libmount1 libmspack0 libpam-modules libpam-modules-bin libpam-runtime libpam-systemd libpam0g libpci3 libperl5.22 libplymouth4 libpng12-0 libpolkit-agent-1-0 libpolkit-backend-1-0 libpolkit-gobject-1-0 libprocps4 libpython3.5 libpython3.5-minimal libpython3.5-stdlib libsasl2-2 libsasl2-modules libsasl2-modules-db libseccomp2 libslang2 libsmartcols1 libsqlite3-0 libssl1.0.0 libsystemd0 libudev1 libuuid1 libx11-6 libx11-data libxml2 libxslt1.1 linux-firmware linux-headers-generic locales login lshw mount multiarch-support ntfs-3g open-iscsi open-vm-tools openssh-client openssh-server openssh-sftp-server openssl overlayroot passwd patch pciutils perl perl-base perl-modules-5.22 plymouth plymouth-theme-ubuntu-text policykit-1 procps python-apt-common python-lxml python3-apport python3-apt python3-distupgrade python3-problem-report python3-requests python3-software-properties python3-update-manager python3-urllib3 python3.5 python3.5-minimal resolvconf rsyslog shared-mime-info software-properties-common sosreport squashfs-tools sudo systemd systemd-sysv tzdata ubuntu-minimal ubuntu-release-upgrader-core ubuntu-server ubuntu-standard udev uidmap update-manager-core update-notifier-common ureadahead util-linux uuid-runtime vim vim-common vim-runtime vim-tiny vlan wget wireless-regdb xdg-user-dirs 2019-09-13 14:10:01,497 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log 2019-09-13 14:10:13,935 WARNING SIGTERM received, will stop 2019-09-13 14:10:16,810 WARNING SIGTERM received, will stop 2019-09-13 14:10:19,803 WARNING SIGTERM received, will stop 2019-09-13 14:10:22,772 WARNING SIGTERM received, will stop 2019-09-13 14:10:22,779 WARNING SIGTERM received, will stop 2019-09-13 14:10:25,764 WARNING SIGTERM received, will stop 2019-09-13 14:10:25,820 WARNING SIGTERM received, will stop 2019-09-13 14:10:28,713 WARNING SIGTERM received, will stop 2019-09-13 14:10:28,873 WARNING SIGTERM received, will stop 2019-09-13 14:10:31,832 WARNING SIGTERM received, will stop 2019-09-13 14:10:34,086 WARNING SIGNAL received, stopping 2019-09-13 14:10:34,697 WARNING SIGTERM received, will stop 2019-09-13 14:10:34,779 WARNING SIGTERM received, will stop ### unattended-upgrades-shutdown.log 2019-09-13 14:09:17,147 DEBUG - Waiting for signal to start operation 2019-09-13 14:09:43,639 DEBUG - Starting countdown of 25.0 minutes 2019-09-13 14:09:43,639 DEBUG - Initializing apt_pkg configuration 2019-09-13 14:09:43,640 DEBUG - starting unattended-upgrades in shutdown mode 2019-09-13 14:09:43,645 WARNING - Running unattended-upgrades in shutdown mode 2019-09-13 14:09:43,645 DEBUG - Running plymouth --text 2019-09-13 14:09:43,657 WARNING - Unattended-upgrade in progress during shutdown, please don't turn off the computer 2019-09-13 14:09:43,657 DEBUG - Running plymouth --text 2019-09-13 14:09:46,643 WARNING - Unattended-upgrade in progress during shutdown, please don't turn off the computer 2019-09-13 14:09:46,644 DEBUG - Running plymouth --text 2019-09-13 14:09:49,647 WARNING - Unattended-upgrade in progress during shutdown, please don't turn off the computer 2019-09-13 14:09:49,648 DEBUG - Running plymouth --text 2019-09-13 14:09:52,650 WARNING - Unattended-upgrade in progress during shutdown, please don't turn off the computer 2019-09-13 14:09:52,651 DEBUG - Running plymouth --text 2019-09-13 14:09:55,654 WARNING - Unattended-upgrade in progress during shutdown, please don't turn off the computer 2019-09-13 14:09:55,654 DEBUG - Running plymouth --text 2019-09-13 14:09:58,656 WARNING - Una
[Bug 1843099] Re: Unattended upgrades does not work on shutdown
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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843099 Title: Unattended upgrades does not work on shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1843099] Re: Unattended upgrades does not work on shutdown
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843099 Title: Unattended upgrades does not work on shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1843099] Re: Unattended upgrades does not work on shutdown
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843099 Title: Unattended upgrades does not work on shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1843099] Re: Unattended upgrades does not work on shutdown
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 member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843099 Title: Unattended upgrades does not work on shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1843099] Re: Unattended upgrades does not work on shutdown
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
unattended-upgradesonly if it is running
2019-09-06 10:54:31,250 DEBUG - Starting countdown of 25.0 minutes
2019-09-06 10:54:31,250 DEBUG - get_lock returned 7
2019-09-06 10:54:31,250 DEBUG - lock not taken
# Tracing manually
/usr/share/unattended-upgrades/unattended-upgrade-shutdown:
L230> 2019-09-06 10:54:31,249 WARNING - SIGTERM or SIGHUP received, stopping
unattended-upgradesonly if it is running
* Bug - add space to end (i.e. "SIGTERM or SIGHUP received, stopping
unattended-upgrades ")
L318> 2019-09-06 10:54:31,250 DEBUG - Starting countdown of 25.0 minutes
L333> 2019-09-06 10:54:31,250 DEBUG - get_lock returned 7
* Bug - The lock should be acquired so it should be 0 ... according to code
but docs say it's fine
L332> res = apt_pkg.get_lock(self.options.lock_file)
L333> logging.debug("get_lock returned %i" % res) # <-- This is where I
believe there's the bug
L334> # exit here if there is no lock
L335> if res > 0:
L336> logging.debug("lock not taken")
L337> if self.lock_was_taken:
L338> exit_log_result(self.signal_sent)
L339> else:
L340> sys.exit(0)
L341> self.lock_was_taken = True
L342> signal_stop_unattended_upgrade()
L343> self.signal_sent = True
L344> # show log
L345> log_progress()
L346> return True
* Looking deeper into get_lock it shows that a file descriptor is returned
vs -1 or an error raised. I believe the code may need to be updated as
running python3 interactively, importing apt_pkg and printing its
__doc__ shows the following. This is Sparta err python 3... so perhaps
that's the reason.
>>> print(apt_pkg.get_lock.__doc__)
get_lock(file: str, errors: bool) -> int
Create an empty file of the given name and lock it. If the locking
succeeds, return the file descriptor of the lock file. Afterwards,
locking the file from another process will fail and thus cause
get_lock() to return -1 or raise an Error (if 'errors' is True).
>From Python 2.6 on, it is recommended to use the context manager
provided by apt_pkg.FileLock instead using the with-statement.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1843099
Title:
Unattended upgrades does not work on shutdown
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1843099] Re: Unattended upgrades does not work on shutdown
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 received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843099 Title: Unattended upgrades does not work on shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1843099] [NEW] Unattended upgrades does not work on shutdown
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 expected to happen * Packages to be upgraded on reboot / shutdown. 4) What happened instead * The host just rebooted. Didn't perform upgrades. No useful output either until I enabled debug logging in the systemd unit file. I'm reporting a new bug but this is very similar to #1806487 and I'm actually wondering if it resurfaced somehow. We're running Ubuntu Xenial 16.04.6 which has 1.1ubuntu1.18.04.7~16.04.3 installed. I see that #1806487 was resolved with 1.1ubuntu1.18.04.7~16.04.2. However I'm seeing similar behavior. So far I've modified systemd to see if anything stands out. I do have an strace and then just debug mode. Unless needed, simply put, this is what a reboot with debug logging looks like (i.e. unattended-upgrades-shutdown.log): 2019-09-06 09:20:04,871 DEBUG - Waiting for signal to start operation 2019-09-06 09:20:43,996 WARNING - SIGTERM or SIGHUP received, stopping unattended-upgradesonly if it is running 2019-09-06 09:20:43,996 DEBUG - Starting countdown of 25.0 minutes 2019-09-06 09:20:43,997 DEBUG - get_lock returned 7 2019-09-06 09:20:43,997 DEBUG - lock not taken I hope that helps, please let me know if you need anything else from me or if I can provide any more information. I've done this many times before, this is the first time it hasn't worked. When I patched around the end of May, all went well. My other variants worked, well mainly Trusty but that's EOL for public access. Bionic doesn't seem to have anything it needs to update. ** Affects: unattended-upgrades (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843099 Title: Unattended upgrades does not work on shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
