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

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

>>> Andrei Borzenkov <arvidjaar@xxxxxxxxx> schrieb am 06.02.2021 um 09:14 in
Nachricht <09aa6a69-ee37-ffea-c4fd-e4c5d3327023@xxxxxxxxx>:
> 04.02.2021 10:47, Ulrich Windl пишет:
...
>> I had provided the full units yesterday. Basically I don't know what to do:

> I
>> just want to start the service and its sockets at a specific point in time

> and
>> also want to stop those at another time.
>> 
> 
> We are going in circles. socket unit is optimization that allows you to
> start service unit on demand instead of starting it unconditionally. If
> you want to start service unit in controlled way (and not when someone
> decides to connect to socket) you should not use socket unit. Period.

All I want is that the sockets that need to listen actually do listen when the
service start.
It seems systemd messes with that in a bad way.

...
>> Pacemaker cluster provides a shared filesystem, so the units should not be
>> started before that filesystem is mounted.
> 
> So what's wrong with starting them before pacemaker? virtlockd even
> supports restarting without losing state.

When the state is left in the (correct) filesystem. Obviously when I mount a
filesystem over the mount point, the locks created before won't be visible any
more.

> 
> But that really goes beyond the scope of this list.

Staring systemd units under pacemaker control only is beyopnd the scope of
this list? Then please drop systemd units from pacemaker.

> 
>> Sounds simple, but systemd seems to make this hard to impossible.
>> 
> 
> If those units are started before pacemaker, they are certainly
> available before any pacemaker resource is activated. What exactly "is
> impossible" here?

pacemaker-controlled systemd units. Specifically virtlockd and libvirtd using
TLS.

> 
> If you insist on putting those applications under pacemaker control then
> you are shooting the messenger. Default units included with libvirt are
> not suitable for use in HA cluster. So do not use them. Create your own

That's complete nonsense: Just dump systemd and you can control your processes
again using pacemaker.

> pacemaker resource agent or create your own unit definition if it must
> be systemd resource. But that again is beyond the scope of this list.
> This should be discussed with libvirt people.

As it seems right now is that units start correctly after a node had been
fenced, but not if pacemaker is restarted on the node. The systemd starts the
units itself. I don't know why, but I suspect "Drop_ins":

h16:~ # ls /run/systemd/system/*irt*
/run/systemd/system/libvirtd.service.service.d:
50-pacemaker.conf

/run/systemd/system/virtlockd.service.d:
50-pacemaker.conf
h16:~ # cat /run/systemd/system/*irt*/50*
[Unit]
Description=Cluster Controlled libvirtd.service
Before=pacemaker.service pacemaker_remote.service

[Service]
Restart=no

[Unit]
Description=Cluster Controlled virtlockd
Before=pacemaker.service pacemaker_remote.service

[Service]
Restart=no

Regards,
Ulrich




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