[systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation
Ulrich Windl
Ulrich.Windl at rz.uni-regensburg.de
Tue Feb 9 08:46:36 UTC 2021
>>> Michael Chapman <mike at very.puzzling.org> schrieb am 09.02.2021 um 09:09 in
Nachricht <cab297-232e-ca89-34fb-8ba108f3c51 at very.puzzling.org>:
> 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
More information about the systemd-devel
mailing list