Hi, Cc-ing 795...@bugs.debian.org by intention as this issue might be fixed then:
* Hans-Kristian Bakke [Thu Apr 13, 2017 at 12:52:15PM +0200]: > Upon further inspection, backups (or actually fs freeze), do not work until > after restarting > qemu-guest-agent. > This is from the systemd journal after boot. Note the "transport endpoint > not found" warning. > #### > Apr 12 16:26:32 cns-2 systemd[1]: Starting LSB: QEMU Guest Agent startup > script... > Apr 12 16:26:32 cns-2 qemu-guest-agent[1126]: qemu-ga: transport endpoint > not found, not starting ... (warning). > Apr 12 16:26:32 cns-2 systemd[1]: Started LSB: QEMU Guest Agent startup > script. [...] > During boot what happens seems to be that > /dev/virtio-ports/org.qemu.guest_agent.0 is not available although it > always is when I check after boot, which of course makes the error > disappear when I restart qemu-guest-agent later. > A simple "sleep 1" in /etc/default/qemu-guest-agent as a ugly hack solves > the issue, so there seems to be some kind of race condition during boot, > with possible a dependency of virtio-serial device that should be > added somewhere > during the boot process. > Although Stretch seems to have no issues I do not know if this is by design > or just that the race condition happens to end differently most of the time. [...] I see the same behavior also on current stretch systems: * Host: Debian/stretch with Proxmox 5.2-2 + pve-qemu-kvm 2.11.1-5 * Guest: Debian/stretch with qemu-guest-agent 1:2.8+dfsg-6+deb9u4 I assume when qemu-guest-agent switches to a native systemd unit as requested in #795486 the problem might disappear, since systemd can bind to/wait for the according device. I found https://github.com/qemu/qemu/tree/master/contrib/systemd and it might be worth just shipping those files with Debian's qemu-guest-agent as well. regards, -mika-
signature.asc
Description: Digital signature
