Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation
>>> Michael Chapman schrieb am 09.02.2021 um 10:17 in Nachricht : > On Tue, 9 Feb 2021, Ulrich Windl wrote: > [...] >> At what timne exactly? When pacemaker starts, or when the systemd using is >> about to be started? > > Pacemaker adds the drop‑in just before it starts the resource, and it > removes the drop‑in just after it stops the resource. It's entire purpose > is to handle the case when Pacemaker and the service are *simultaneously* > stopped (i.e. by something external to Pacemaker). > > Without the drop‑in, what can happen is that the service is stopped before > Pacemaker thinks it should be stopped... which makes Pacemaker attempt to > recover the resource... which makes every go wrong quickly. Yeah two resource managers is one too many (much?). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation
On Tue, 9 Feb 2021, Ulrich Windl wrote: [...] > > > > 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? Follow the link. It's all described there. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation
On Tue, 9 Feb 2021, Ulrich Windl wrote: [...] > At what timne exactly? When pacemaker starts, or when the systemd using is > about to be started? Pacemaker adds the drop-in just before it starts the resource, and it removes the drop-in just after it stops the resource. It's entire purpose is to handle the case when Pacemaker and the service are *simultaneously* stopped (i.e. by something external to Pacemaker). Without the drop-in, what can happen is that the service is stopped before Pacemaker thinks it should be stopped... which makes Pacemaker attempt to recover the resource... which makes every go wrong quickly. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation
>>> Michael Chapman schrieb am 09.02.2021 um 09:15 in Nachricht <20675743-9521-cdca-1c58-d42de7117...@very.puzzling.org>: > 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation
>>> Michael Chapman schrieb am 09.02.2021 um 09:09 in Nachricht : > On Tue, 9 Feb 2021, Ulrich Windl wrote: > [...] >> As for the drop‑ins: I neither know what those are expected to do, not who >> adds them at run time. See "documentation"... > > The 50‑pacemaker.conf drop‑ins are, as their name suggests, created by > Pacemaker. Hi Michael, thanks for explaining! > > Specifically, Pacemaker's systemd resource agent [1] creates a drop‑in on > each Pacemaker‑managed systemd service. Consider the situation where both At what timne exactly? When pacemaker starts, or when the systemd using is about to be started? > Pacemaker and the Pacemaker‑managed service are scheduled to be stopped > (e.g. you're rebooting the entire system). Either you want Pacemaker to > stop the service itself (and, perhaps, start the service on some other > node in your cluster), or ‑‑ if the pacemaker resource has management > disabled ‑‑ you want the service to be stopped *after* Pacemaker has been > stopped. Either way, the service needs to be ordered > Before=pacemaker.service. This is precisely what that drop‑in does. But doesn't "Before=pacemaker.service" say the corresponding service is to be *started* *before* pacemaker? If that's the case any ordering attempts inside the pacemaker configuration do not make any sense. Likewise when shutting down: If a systemd service needs some other pacemaker service it would be stopped *after* pacemaker. Sorry I don't understand that. > > 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. Yes, that is what I wanted, and it seems it works after a reboot of the node, but not when pacemaker had been running once. > > For more help on this drop‑in in particular, I think you'd be better off > contacting the Pacemaker developers. > > [1] > https://github.com/ClusterLabs/pacemaker/blob/master/lib/services/systemd.c Actually I had been raising the issue there too (after haing googled the topic). As it seems *nobody* managed to create the configuration I want. Probably I should dump all that libvirt stuff and ose the plain Xen RA until people fixed the mess, making it ready for actual use. Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
