Hi Christian, On Wed, Apr 01, 2020 at 01:27:54PM +0200, Christian Ehrhardt wrote: > Package: debhelper > Version: 12.10 > X-Debbugs-CC: a...@sigxcpu.org > > Hi, > I've seen this in package libvirt in Ubuntu as well as Debian, but it > might be more widespread without me being aware of it. If we install > the package all is fine, but on a --reinstall or upgrade it will show > warnings about services like: > > Setting up libvirt-daemon-system (6.0.0-0ubuntu6) ... > Job failed. See "journalctl -xe" for details. > > It comes down to: > systemd[1]: libvirtd-ro.socket: Socket service libvirtd.service > already active, refusing. > but I was tracking that down for [1] and it is more complex than just that. > I found the ordering of sockets mentioned as "Also" to be the reason, > let me outline the details ... > > libvirtd.service has a few related sockets. > $ grep Also /lib/systemd/system/libvirtd.service > Also=virtlockd.socket > Also=virtlogd.socket > Also=libvirtd.socket > Also=libvirtd-ro.socket > > Due to that the following entry in d/rules: > dh_installsystemd -p libvirt-daemon-system --restart-after-upgrade > libvirtd.service > > Gets generated into postinst automatically pulling in all the "Also" > statements. > But also ordering them alphabetically. > > if [ -n "$2" ]; then > _dh_action=restart > else > _dh_action=start > fi > deb-systemd-invoke $_dh_action 'libvirtd-ro.socket' 'libvirtd.service' > 'libvirtd.socket' 'virtlockd.socket' 'virtlogd.socket' >/dev/null || > true > > Due to that the "libvirtd-ro.socket" is restarted before the service > and fails as the service is already up. The sockets listed later work > fine. > > The following order would work fine (service first, then sockets): > $ deb-systemd-invoke restart 'libvirtd.service' 'libvirtd-ro.socket' > 'libvirtd.socket' 'virtlockd.socket' 'virtlogd.socket > (but IMHO that might be racy still). > > I was wondering if dh_installsystemd should maybe: > A) always order the service it was called with as first entry? > B) not pull in "ALSO" statements if they are sockets? > C) add an option to influence that behavior as needed per-package? > D) ... ? > > I'm a bit lost on what the best option might be, therefore I wanted to > open this bug for a discussion.
I accidentally looked into the same thing yesterday and from what i found the problem is not the ordering but rather the relationship between libvird.socket, libvirtd-ro.socket and libvirtd.service. If you e.g. restart libvirtd.socket (which is what happens in the postinst) yet get: $ sudo systemctl restart libvirtd.socket Job failed. See "journalctl -xe" for details. and in the journal: Apr 01 14:12:07 foo systemd[1]: libvirtd.socket: Socket service libvirtd.service already active, refusing. Apr 01 14:12:07 foo systemd[1]: Failed to listen on Libvirt local socket. But if you do: $ sudo systemctl stop libvirtd.service libvirtd-ro.socket sudo systemctl restart libvirtd.socket [no error printed] So the problem to me looks like the socket service trying to start an already running daemon backed by .service unit. So (if what we do here is valid) it looks like a systemd issue (otherwise it would be within libvirt itself). I assume what we do *is* valid on the libvirt side since this also reproduces the problem: $ sudo systemctl stop libvirtd.service $ sudo systemctl start libvirtd.socket libvirtd-ro.socket $ ps awux | grep -qs [l]ibvirtd || echo "Libvirtd not running" Libvirtd not running # trigger libvirtd start via socket: $ virsh list $ sudo systemctl restart libvirtd.socket Job failed. See "journalctl -xe" for details. So the problem seems to be that systemd prints that warning whenever you try to restart a socket activated service that is already active and also backed by a .service unit - and it doesn't matter whether it's activated by socket or via the service file). Does that make sense? Cheers, -- Guido > > [1]: https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1869796 > > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd >
