What is the limit on the number of directories that may be watched with a recursive watcher?

[veqryn]

I saw two unresolved issues referencing the fact that this package can stop watching directories if there are too many, but without throwing an error or alerting to that fact. Since that is the case, how many directories can be watched on a linux system?
If it is specific to each server, how do I figure out this number?

Also, is there a way to exclude certain directories from a recursive watch?

[ppknap]

Hey @veqryn !

how many directories can be watched on a linux system?

It depends on the number of "watch descriptors" allowed by your kernel.

If it is specific to each server, how do I figure out this number?

Yes, it is. You can tweak the number with max_user_watches setting. More info here.

Also, is there a way to exclude certain directories from a recursive watch?

Unfortunately, notify doesn't have built-in file filters. See #79 for more details.

[veqryn]

Thanks.

Is there a way to tell, within this library or within golang, when you've run out of watch descriptors?

[ppknap]

At this moment there is no clean solution for detecting watch descriptors overflow in notify. The simplest one is to just return an error when creating watchers. This was implemented but, due to some resource leakage issues, we decided that it won't be merged.

If you need this behavior, you can fork the project and apply this path.

[EDIT] @Zillode's notify fork has exactly what you need.

[veqryn]

A watch descriptor is needed for each directory on linux, correct? So when the watcher is created there might only be one directory, and no overflow in watch descriptors. Later, subdirectories might get created, overflowing the watch descriptors (I assume this is how it works?). If the overflow could occur after the initial watch is created, then you may actually need an error channel, rather than just returning an error at creation time.

[rjeczalik]

If the overflow could occur after the initial watch is created, then you may actually need an error channel, rather than just returning an error at creation time.

Yes and no. The solution we were also considering is to handle the error gracefully - fallback to polling on fstat, so the events keep coming. Either solution (an error chan or graceful handling) would require an extended API, which is something we did not agree yet on and are no working on currently. Unfortunately.

[veqryn]

K, thanks for the insight. I'll close this now.