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:09 in
Nachricht <cab297-232e-ca89-34fb-8ba108f3c51@xxxxxxxxxxxxxxxxx>:
> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel