[systemd-devel] Antw: [EXT] Re: Still confused with socket activation

[Andrei Borzenkov]

04.02.2021 10:47, Ulrich Windl пишет:
>>>> Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 03.02.2021 um 19:13 in
> Nachricht <bbbd0698-2248-4541-fd28-ebf3757b8994 at gmail.com>:
>> 02.02.2021 12:43, Ulrich Windl пишет:
>>> Hi!
>>>
>>> Having:
>>> ---
>>> # /usr/lib/systemd/system/virtlockd.service
>>> [Unit]
>>> Description=Virtual machine lock manager
>>> Requires=virtlockd.socket
>>> Requires=virtlockd-admin.socket
>>
>> That's always wrong with After for the same units unless you can prove
>> that both socket units are always ordered Before service unit due to
>> dependency chain, at least if intention is to ensure socket units are
>> active *before* service unit. In real life nobody notices it because
>> both sockets are started much earlier which papers over race condition.
>>
>> And if after 10 years of software existence everyone still gets it wrong
>> I strongly suspect something is not right with software, not with everyone.
>>
>>> Before=libvirtd.service
>>> ...
>>> ---
>>>
>>> How would I start both sockets successfully unter program control?
>>
>> I do not understand what you want to say here, sorry. What "program
>> control" means? What exactly are you trying to do?
> 
> "program control" means "start"/"stop" vs. automatic control via
> "enable"/"disable".
> 
>>
>>> If I start one socket, I cannot start the other without an error (as 
>> libvirtd.service is running already, see my earlier message from last
> week).
>>
>> I do not see how starting socket unit is related to starting service
>> unit. Unless there was incoming traffic on socket. Also I do not
>> understand why you need to start socket units if you *already* started
>> service unit. Again, you do not really provide much coherent information
>> to do any suggestion.
> 
> 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.

>>
>> And I do not really understand the reason to use two different socket
>> units that apparently are always started together and activate the same
>> service. Just create single socket unit that listens on both sockets.
> 
> It seems the service has a config file that specified which sockets to use,

Do you mean "config file used by your application" or what?

> and some magic has to activate/deactivate the corresponding socket units.
> (BTW: You can find a corresponding question at serverfault since yesterday)
> 

You probably mean "service unit definition" when you say "config file"
then. In this case I still do not understand how it is relevant. You do
not want to enable units so it is irrelevant what those unit definitions
have in [Install] section.

>>
>>> If I mask the socket units, I cannot start the libvirtd.service.
>>> So would I disable the socket units and start libvirtd.service?
>>
>> You misunderstand what "disable" means in systemd (see remark above).
>> You cannot disable (in common sense) starting of socket units together
>> with virtlockd.service because starting of virtlockd.service will always
>> attempt to start both socket units (that is exactly what Requires/Wants
>> are about).
> 
> That would be OK, but I don't want that the socket units get activated by some
> otherm echanism I still haven't identified.
> 

If you mean to say "you observed that socket unit was activated even
though it was disabled and no corresponding service unit was being
activated" - you did not show any evidence of it so far.

If this is generic request - there is no way to prevent it in systemd.
At most you can set RefuseManualStart, but any other unit can always add
Requires/Wants=your-socket-unit.socket and your-socket-unit.socket will
be activated together with this other unit.

>>
>> Actually if they are "enabled" (in systemd sense) then they are started
>> very early during boot, long before service unit. What exact problem you
>> have in this case?
> 
> 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.

But that really goes beyond the scope of this list.

> 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?

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
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.