[systemd-devel] Question: path-based deactivation or equivalent

[Lennart Poettering]

On Di, 26.09.17 16:15, matthew at giassa.net (matthew at giassa.net) wrote:

>   I have a project where I'm adding some services to a Raspberry Pi 3,
> and have decided to go with systemd being (mostly) responsible for
> launching all of the services. All of the server processes use a common
> API to do some initial setup (argument parsing, init, etc), drop root
> permissions, and then carry out their normal duties. One of these
> services is the "master" service, which I want to use to
> activate/deactivate other services on-demand.
> 
>   I started out with path-based activation via systemd, and that
> worked fine for bringing up the services as I requested them.  However,
> it seems there is no equivalent path-based deactivation functionality at
> this time [1], so it's definitely not an option on the older OS deployed
> on my dev board.

Unit deactivation triggered by fs events has been requested before
(there's a github RFE issue about it somewhere), but I am not
convinced this is a good idea, and the semantics aren't clear about it
at all.

First of all, the states of .path units and the units they trigger are
actually connected: as long as the service a .path is supposed to
trigger is running the .path unit is in a "dormant" mode, and won't
care for any fs events, until the service is terminated again, at
which point the state is rechecked and things might trigger
again. This scheme is not compatible with .path based deactivation
really...

The other thing is: i fail to see the usecase. Things like PathExists=
and DirectoryNotEmpty= have a clear usecase where they aren't racy:
they trigger a service that processes files that are created somewhere
and delete the files when they are done with them. As long as there
are files there, the service will be restarted. And the service is
supposed to exit when it's done.

Now, if you want to use .path just a communication protocol: there are
way better ways to solve that. use systemctl, or use the D-Bus
API. File system objects are not a great replacement for an IPC.

Lennart

-- 
Lennart Poettering, Red Hat