On Fri, Feb 21, 2014 at 02:25:24PM +0100, Michal Privoznik wrote: > On 21.02.2014 13:50, Daniel P. Berrange wrote: > >On Fri, Feb 21, 2014 at 01:32:36PM +0100, Michal Privoznik wrote: > >>I've noticed that in some cases systemd was quick enough and even > >>if libvirt-guests.service is marked to be started after the > >>libvirtd.service my guests were not resumed as > >>libvirt-guests.sh failed to connect. This is because of a > >>simple fact: systemd correctly starts libvirt-guests after it > >>execs libvirtd. However, the daemon is not able to accept > >>connections right from the start. It's doing some > >>initialization which may take ages. This problem is not limited > >>to systemd only, indeed. Any init system that is able to startup > >>services in parallel (e.g. OpenRC) may run into this situation. > >>The fix is to try connecting not only once, but continuously a few > >>times with a small sleep in between tries. > > > >The long term fix for this will be to use socket activation for > >libvirtd. Unfortunately we can't do that yet since then VMs marked > >to autostart on boot won't be booted > > I think that we can create a .socket within libvirt and set > libvirt-guests.service to be dependent on the libvirt.socket. > Something among: > > diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in > index e1f2a07..35963ce 100644 > --- a/daemon/libvirtd.service.in > +++ b/daemon/libvirtd.service.in > @@ -22,5 +22,9 @@ Restart=on-failure > # Override the maximum number of opened files > #LimitNOFILE=2048 > > +[Socket] > +ListenStream=/var/run/libvirt/libvirt-sock > +ListenStream=0.0.0.0:16509 > + > [Install] > WantedBy=multi-user.target > diff --git a/tools/libvirt-guests.service.in > b/tools/libvirt-guests.service.in > index d8d7adf..03120da 100644 > --- a/tools/libvirt-guests.service.in > +++ b/tools/libvirt-guests.service.in > @@ -1,6 +1,6 @@ > [Unit] > Description=Suspend Active Libvirt Guests > -After=network.target libvirtd.service > +After=network.target libvirtd.socket > Documentation=man:libvirtd(8) > Documentation=http://libvirt.org Hmm, i guess that would work in fact, provided we ensured that the main libvirtd.service was still always enabled by default too. > My inspiration comes from here: > > https://bugzilla.redhat.com/show_bug.cgi?id=714426 > > However, I was unable to make this work with this particular change. You need to also make libvirtd receive the socket file handle from systemd, and create the libvirtd.socket file too. See what the virtlockd daemon does in this regard. > Moreover, it would require users to adjust libvirtd.service file if > they ever change socket path or listen address. That's why I've > decided for approach implemented in 3/3. Sure, patch 3 is fine regardless because it gives fine grained synchronization of startup beyond simply the socket availability. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list