Antw: Re: Antw: [EXT] Re: Still confused with socket activation

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Michael Chapman <mike@xxxxxxxxxxxxxxxxx> schrieb am 09.02.2021 um 09:15 in
Nachricht <20675743-9521-cdca-1c58-d42de7117e51@xxxxxxxxxxxxxxxxx>:
> On Tue, 9 Feb 2021, Michael Chapman wrote:
> [...]
>> Note that when you're using Pacemaker to manage a systemd service, you 
>> should not enable the service in the normal way ‑‑ that is, the service 
>> should not be started simply by virtue of it being in the Wants= list of 
>> multi‑user.target. The service is intended to be started and stopped only 
>> by Pacemaker.
> 
> Ah, there's something else I forgot to mention.
> 
> Since Pacemaker is in charge of the service's lifecycle, you almost 
> certainly *do not* want it to be socket‑activated.

Hi Michael!

Thanks and "back to the mess": If I use libvirtd.service instead of
libvirtd-tls.socket, it does *not* open the TLS socket, even though the
configuration file contains "listen_tls=1"... Support was telling me I should
"probably" use libvirtd-tls.socket instead of libvirtd.service... "The wheel
has come full circle" said Shakespeare (AFAIR)

> 
> libvirt can be run without socket activation [2]. I strongly recommend you 
> configure it this way if you intend to manage libvirt in Pacemaker.

Yes, I'd like to! Any pointers?

> 
> (I think managing libvirt in Pacemaker is a mistake, mind you. Sure, 
> manage individual libvirt *guests* in Pacemaker. But managing libvirt as a 
> whole from Pacemaker seems to be the wrong approach.)

As libvirtd has a dependency on virtlockd, and when using indirect locks,
virtlockd has a dependency on a (thinking multi-node) cluster-wide filesystem
(like OCFS2), you *must* start virtlockd *after* the cluster filesystem had
been mountd. Naturally libvirtd cannot be started before virtlockd, so you'll
have what I'm trying to manage.

As indicated before, I had asked a similar question at "superuser", but nobody
had an answer so far...

> 
> [2] https://libvirt.org/daemons.html 

Regards,
Ulrich


_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel