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

[Matthew Giassa]

I've been considering the dbus API, as I arrived at a similar conclusion while researching this last night. The downside is that, since some services are provided to me in binary form only, I can't deploy it across all daemons. 

In short, I'd be happy with just being able to send SIGTERM and SIGKILL to systemd-managed daemons, along with spawning them on-demand, without having to do something along the lines of execve(systemctl...) (i.e. Directly via a C/C++ API), and not requiring root privileges to issue the call. ‎I don't see a way to do this directly via systemd without wrapping systemctl. 

Thank you for the feedback.

Sent from my BlackBerry 10 smartphone on the Bell network.
  Original Message  
From: Lennart Poettering
Sent: Wednesday, September 27, 2017 9:54 AM
To: matthew at giassa.net
Cc: systemd-devel at lists.freedesktop.org
Subject: Re: [systemd-devel] Question: path-based deactivation or equivalent

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