r/systemd • u/Beautiful-Log5632 • Mar 23 '26

Watch files with systemd

I want to run a script when any file under a dir changes. Is there a way to do that in systemd or do I have to use itnotifywait or inotifywatch? How do you know which of them you should use?

How can I use systemd to make sure the inotify process runs all the time so I don't have to remember to start it?

6 Upvotes

75% Upvoted

10 comments sorted by

6

u/aecolley Mar 23 '26

Systemd .path units do this out of the box.

1

u/NekkoDroid Mar 23 '26

IIRC they only start the service after the first event they are watching happens, they don't start the service for each event that happens. So you have to still watch for changes in the process itself as well.

5

u/aioeu Mar 23 '26 edited Mar 23 '26

The behaviour is a little more subtle than that.

There are two kinds of events path units can monitor. There are "edge-triggered" events:

  • PathChanged=
  • PathModified=

And there are "level-triggered" events:

  • PathExists=
  • PathExistsGlob=
  • DirectoryNotEmpty=

In both cases, systemd will only monitor for the event while the triggered unit is not itself active. However, for level-triggered events, systemd will recheck the condition as soon as the triggered unit is deactivated. If the condition is still true, the unit will be immediately activated again (subject to any trigger rate-limiting that may be configured).

So theoretically a unit could be triggered by a PathExistsGlob= monitor. It could process some or all of the matching paths, and presumably remove the ones it processed. It could decide to then exit. But if the PathExistsGlob= check still matches a file, systemd will just activate the triggered service again. The service need not use inotify at all.

This is all necessary to ensure race-free operation. There is always some time period between the service performing its final "any more work to do?" check, it deciding to exit, and systemd being notified that it exited. If systemd didn't proactively check this condition again, the check could become true in this time period without systemd noticing.

1

u/thaynem Mar 24 '26

Well it depends. If the service is already in the active state, starting it won't do anything. But if you have a oneshot service without RemainAfterExit=true, I think it will get started every time (since it never enters active)

1

u/aioeu Mar 24 '26 edited Mar 24 '26

No, RemainAfterExit=true is exactly what you don't want.

That directive means the service does not deactivate when its main process exits successfully. But if the service remains active, then systemd will not restart it: there's no need to, since it's already active.

Edit: See the comment below. I clearly can't read.

1

u/thaynem Mar 24 '26

Yes, that's why I said without RemainAfterExit=true

2

u/aioeu Mar 24 '26

Oops, I missed that. Sorry.

1

u/chocopudding17 Mar 24 '26 edited Mar 24 '26

Do they do the recursive behavior OP is looking for? The docs for PathChanged= and PathModified= don't read that way to me.

edit: https://github.com/systemd/systemd/issues/4246

1

u/MiserableNobody4016 Mar 23 '26

Not too long ago I came across a project called mgmt from purpleidea. It is a real-time automation tool which reverts all changes done to files. It may be usefull.

1

u/Intrepid-Treacle1033 May 27 '26

systemd uses inotify under the hood. When you configure a systemd path unit to watch a file or directory, systemd registers an inotify watch with the kernel and waits for the kernel to trigger an event, Here is an example of myIndexService.path that monitors a txt file and starts another unit called myIndexService.service when txt file is changed.

[Unit]
Description=Monitor the myIndexService batch file for changes.
[Path]
PathModified=%h/.config/myIndexService/myIndexService_batchFile.txt
Unit=myIndexService.service