GNU bug report logs -
#33265
[WIP RFC] services: Add file system monitor service.
Previous Next
Full log
Message #35 received at 33265 <at> debbugs.gnu.org (full text, mbox):
Hello!
Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
> On Sat, 10 Nov 2018 23:19:53 +0100
> ludo <at> gnu.org (Ludovic Courtès) wrote:
>
>> Nice! Should we call it ‘fswatch-monitoring-service’, since there may
>> be other tools to achieve similar results?
>
> Its use is mostly to allow other Guix services to extend it in order to
> do stuff on file change (for example restarting a service; starting the
> user shepherd - the latter is what caused me to write this).
>
> I was very much tempted to call it "fswatch-monitoring-service", but that's
> really an implementation detail - what it does is provide file change
> notification services to other Guix services.
>
> It's not meant to be a generic fswatch service. I've not known fswatch
> before writing this service - so it's pretty likely that there are tons
> more features an fswatch user could want to use which the service doesn't
> provide. Also, fswatch isn't really meant to be used as a daemon AFAIK,
> so we are not providing fswatch to the user in the way it's supposed to be
> used by him.
OK, that makes sense.
>> The ‘sleep’ call looks suspicious. :-)
>
> Pretty suspicious :)
>
> Right now, the service has only a very narrow usecase where rapid
> notifications is not something one wants. On the contrary, both rapid
> notifications and (in a pathological case where a watch couldn't be
> registered - see the "/does_not_exist" workaround) rapid fswatch invocations
> would waste (potentially enormous amounts of) cpu time and would
> forkbomb fswatch, shepherd and/or worse things. On the other hand, using
> fswatch like we do now causes us to lose events. But so does starting fswatch
> later than the clients. And most fswatch backends (for example the Linux one)
> can lose events anyway (since the kernel buffer is limited - Linux will then
> drop events). That's why it always calls the handlers when restarting - just
> in case.
Uh, not very confidence-inspiring. ;-)
>> IIUC, the service stops (and is respawned) every time an even[t] occurs, is
>> that right?
>
> Yes. It's very simple :)
OK that works, but I’m not very comfortable with the approach: normally
respawns indicate that the service failed unexpectedly, so here we’re
really abusing the mechanism IMO.
>> Can’t we instead remove ‘--one-event’ and pass fswatch a script to run?
>
> Not to my knowledge. It would be nice...
Another option would be to use Direvent, which supports this and more,
or maybe ‘inotifywatch’ from inotify-tools though it seems to be quite
similar to fswatch feature-wise.
WDYT?
Ludo’.
This bug report was last modified 6 years and 216 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.