RFE: systemd.path should support deactivation

[Andrei-Pozolotin]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

230

conspicuously, systemd.path mentiones only activation, but not deactivation
https://www.freedesktop.org/software/systemd/man/systemd.path.html

which is confirmed by the following test:

1. debug log of creating a path, followed by target service/start:

Jul 01 20:33:20 serv1 systemd[1]: tape1.path: Got triggered.
Jul 01 20:33:20 serv1 systemd[1]: tape1.service: Trying to enqueue job tape1.service/start/replace
Jul 01 20:33:20 serv1 systemd[1]: tape1.service: Installed new job tape1.service/start as 640
Jul 01 20:33:20 serv1 systemd[1]: tape1.service: Enqueued job tape1.service/start as 640
Jul 01 20:33:20 serv1 systemd[1]: tape1.path: Changed waiting -> running
Jul 01 20:33:20 serv1 systemd[1]: tape1.service: Job tape1.service/start finished, result=done

2. debug log of deleting a path, NOT followed by target service/stop:

Jul 01 20:33:53 serv1 systemd[1]: tape1.path: Changed running -> waiting

in other words, systemd.path initiates systemd.service/start actions for path activation (file created), but does not initiate systemd.service/stop actions for path deactivation (file deleted), despite properly detecting inotify events
https://github.com/systemd/systemd/blob/master/src/core/path.c

test units

test unit.path:

# {{ ansible_managed }}
[Unit]
Description=Tape Path {{ tape_name }}
DefaultDependencies=no
Before=shutdown.target
Conflicts=shutdown.target
[Path]
PathExists={{ tape_part }}
[Install]
WantedBy=multi-user.target

test unit.service:

# {{ ansible_managed }}
[Unit]
Description=Tape Service {{ tape_name }}
DefaultDependencies=no
Before=umount.target shutdown.target
Conflicts=umount.target shutdown.target
[Service]
Type=oneshot
TimeoutSec=0
RemainAfterExit=true
ExecStart=/etc/systemd/system/tape.sh mode=start name={{ tape_name }} part={{ tape_part }}
ExecStop=/etc/systemd/system/tape.sh mode=stop  name={{ tape_name }} part={{ tape_part }}

[bkylerussell]

Somewhat along the same lines, I have a path activated service who loads the watched path as an EnvironmentFile, since it contains configuration for the service's daemon. If that path changes (PathChanged or PathModified), the service just gets another start.

https://github.com/systemd/systemd/blob/master/src/core/path.c#L481

Could JOB_RELOAD_OR_START work here instead? If the service could receive a reload, I could do something like the ExecReload example suggests in the systemd.service man page (assuming I make my daemon load the configuration file internally instead of using EnvironmentFile, and also handle SIGHUP to get notified of the change). Just receiving another start activation when monitoring PathChanged or PathModified doesn't seem to be very helpful to the path's service when long-running. Or is there a better way to handle this scenario all together?

Also, reload seems nicer than a restart, since currently PathChanged\PathModified don't force any action on already running services, and since ExecReload is an optional directive.

I'll be glad to put together a patch, but I wanted to make sure my scenario was keeping with the intent behind the design.

[flavius]

Any news about this? It would be really nice if, when a path is removed, the .path unit is also set back to "waiting".

[Andrei-Pozolotin]

@bkylerussell Kyle: please send the patch? Thank you.

[AHeinlein]

Is someone working on this? Would be really useful for me.

[midulee]

I agree too, I believe the feature is very useful.
Currently, I have no idea why systemd doesn't support it.

[jamestiotio]

I think there are valid use cases for this feature as mentioned in this thread and #3866.

I am not sure about the design intent but I can try to get a patch and PR up and kick off the discussions on the specific implementation details from there.

[akarasulu]

It is completely surprising to see such a feature not implemented. It's so natural to expect it and there are myriads of scenarios that would benefit from it. What exactly is the blocker with adding it? The path unit is IMHO incomplete without this.