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

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

>>> Andrei Borzenkov <arvidjaar@xxxxxxxxx> schrieb am 03.02.2021 um 19:13 in
Nachricht <bbbd0698-2248-4541-fd28-ebf3757b8994@xxxxxxxxx>:
> 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.

> 
> 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,
and some magic has to activate/deactivate the corresponding socket units.
(BTW: You can find a corresponding question at serverfault since yesterday)

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

> 
> 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.
Sounds simple, but systemd seems to make this hard to impossible.

Regards,
Ulrich

> 
>> Unfortunately if someone (update when vendor-preset is enabled) re-enables

> the socket units, it would break things, so I tried to mask them, but that 
> failed, too.
>> error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is 
> masked.
>> 
>> Regards,
>> Ulrich
>> 
>> 
>> 
>> 
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel@xxxxxxxxxxxxxxxxxxxxx 
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 
>> 
> 
> _______________________________________________
> systemd-devel mailing list
> systemd-devel@xxxxxxxxxxxxxxxxxxxxx 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 



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