Package: qemu-guest-agent
Version: 1:7.2+dfsg-7+deb12u3
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu
Hi,
today I noticed one of my VMs was not accessible via the guest agent. Turns out
that during upgrade it was stopped, but not restarted again. Since it can be
used for automation, I believe it's crucial that qemu-ga service tries harder to
stay alive.
Terminal logs below.
--->8----->8----->8----->8----->8----->8----->8----->8----->8----->8--
root@comms:~# systemctl status qemu-guest-agent.service
○ qemu-guest-agent.service - QEMU Guest Agent
Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
Active: inactive (dead) since Sun 2023-12-10 06:36:40 CET; 1 month 18 days
ago
Duration: 1month 3w 16h 24min 38.992s
Main PID: 205124 (code=exited, status=0/SUCCESS)
CPU: 1min 46.804s
Nov 30 17:42:36 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619187
Nov 30 17:42:36 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619187
Nov 30 17:42:37 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619187
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619187
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec called: "/bin/sh -c rm
-f -r /root/.ansible/tmp/ansible-tmp-1701362549.8043833-135706-120368687298004/
> /dev/null 2>
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619913
Dez 10 06:36:40 comms systemd[1]: Stopping qemu-guest-agent.service - QEMU
Guest Agent...
Dez 10 06:36:40 comms systemd[1]: qemu-guest-agent.service: Deactivated
successfully.
Dez 10 06:36:40 comms systemd[1]: Stopped qemu-guest-agent.service - QEMU Guest
Agent.
Dez 10 06:36:40 comms systemd[1]: qemu-guest-agent.service: Consumed 1min
46.804s CPU time.
root@comms:~# systemctl start qemu-guest-agent.service
root@comms:~# systemctl status qemu-guest-agent.service
● qemu-guest-agent.service - QEMU Guest Agent
Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
Active: active (running) since Sat 2024-01-27 22:32:06 CET; 2s ago
Main PID: 1263386 (qemu-ga)
Tasks: 2 (limit: 9475)
Memory: 1.8M
CPU: 28ms
CGroup: /system.slice/qemu-guest-agent.service
└─1263386 /usr/sbin/qemu-ga
Jan 27 22:32:06 comms systemd[1]: Started qemu-guest-agent.service - QEMU Guest
Agent.
root@comms:~# cat /lib/systemd/system/qemu-guest-agent.service
[Unit]
Description=QEMU Guest Agent
BindsTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
After=dev-virtio\x2dports-org.qemu.guest_agent.0.device
[Service]
ExecStart=-/usr/sbin/qemu-ga
Restart=always
RestartSec=0
[Install]
root@comms:~# zless /var/log/apt/history.log.1.gz
Start-Date: 2023-12-10 06:36:40
Commandline: /usr/bin/unattended-upgrade
Upgrade: qemu-guest-agent:amd64 (1:7.2+dfsg-7+deb12u2, 1:7.2+dfsg-7+deb12u3),
qemu-utils:amd64 (1:7.2+dfsg-7+deb12u2, 1:7.2+dfsg-7+deb12u3)
End-Date: 2023-12-10 06:36:42
--->8----->8----->8----->8----->8----->8----->8----->8----->8----->8--
Looking at the maintainer scripts, it looks like it gets stopped by this
section in the .preinst:
# End automatically added section
# Automatically added by dh_installsystemd/13.11.4
if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d /run/systemd/system ]
; then
deb-systemd-invoke stop 'qemu-guest-agent.service' >/dev/null || true
fi
# End automatically added section
And nothing ever starts it again. My next guess was that the systemd unit might
not have been enabled, so I tried that:
root@comms:~# systemctl enable qemu-guest-agent.service
Synchronizing state of qemu-guest-agent.service with SysV service script with
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable qemu-guest-agent
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
It seems like it's only enabled by the udev device trigger, which is never
triggered on upgrade.
I think it's missing a `systemctl start qemu-guest-agent` in .postinstall, do
you agree?
Greets,
Lee
-- System Information:
Debian Release: 12.4
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990,
'proposed-updates'), (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages qemu-guest-agent depends on:
ii init-system-helpers 1.65.2
ii libc6 2.36-9+deb12u3
ii libglib2.0-0 2.74.6-2
ii libnuma1 2.0.16-1
ii libudev1 252.21-1~deb12u1
ii liburing2 2.3-3
qemu-guest-agent recommends no packages.
qemu-guest-agent suggests no packages.
