Re: Using *.path units without races?

[Michael Chapman <mike@xxxxxxxxxxxxxxxxx>]

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.
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel