[systemd-devel] Using *.path units without races?
Michael Chapman
mike at very.puzzling.org
Fri Mar 20 01:25:21 UTC 2020
On Fri, 20 Mar 2020, Uwe Geuder wrote:
[...]
> > PathChanged= and PathModified= each map down to a set of inotify
> > events. It's the kernel's inotify system that determines whether the
> > file changed or modified, not systemd.
>
> My understanding is that since
> https://github.com/systemd/systemd/pull/13509/commits/06582e42de65a61d0238a18720a12b6353edb7cd
> there are 2 states
>
> 1. While the path unit is waiting and the triggered service unit is dead
> its indead all inotify's business. When a change happens the kernel will
> notify systemd.
>
> 2. However, while the triggered service unit is running also the path
> unit is running and the inotify fd is closed. So the kernel will not
> report any changes to systemd at all during that time.
Yes, I agree, this does seem like a regression to me.
I'm actually a bit lost with all the changes that have happened to path
units over the last year. It looks like this issue:
https://github.com/systemd/systemd/issues/12801
is significant, since the reporter had a similar problem to the one you
had: that is, a file created while the triggered service was active would
not be picked up by PathExists=.
But that issue was closed with a commit that fixed a side-issue -- that
reloading or restarting the daemon would cause the service to be triggered
-- and not the issue that the reporter had!
And worse yet, I'm not even sure that side-issue is actually an issue. If
these predicates are supposed to be level-triggered, and the predicate
passes (e.g. the monitored path exist), then it shouldn't matter whether
daemon-reload causes a retrigger, since the retriggered unit should
already be active. "Retriggering" it would be a no-op.
So... yeah, I'm really confused too.
More information about the systemd-devel
mailing list