[bug#33265] [WIP RFC v4] services: Add file system monitoring service.

[Ludovic Courtès]

Hello!

Danny Milosavljevic <address@hidden> skribis:

> On Sat, 10 Nov 2018 23:19:53 +0100
> address@hidden (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’.