Error: cannot send event from fs watcher: no available capacity

[bruceg]

Running watchexec version 1.18.0 through 1.18.2 prints out the following line hundreds of times when the subprogram modifies files.

[[cannot send event from fs watcher: no available capacity]]

When this happens, I am unable to stop watchexec from the terminal using Control-C or with kill (SIGTERM). Only kill -KILL works to stop it.

Version 1.17.1 and earlier do not exhibit this behavior.

I am currently using this with watchexec --debounce 500 -- cargo check --workspace … (yes, I am aware of cargo watch but the cargo check was actually part of a script that does a couple other non-cargo checks)

[passcod]

(you can still use cargo watch, eg with -s)

What OS is this? What are you watching?

I've got a remediation in mind, I'll see what I can do tonight

[bruceg]

This is Arch Linux, kernel version 5.16.2. I am running this in the Vector source tree.

[passcod]

I know this makes 1.18 useless for you, and I'm sorry for that, but I've got no bandwidth for the proper fix tonight and possibly the rest of the week; I'll try to get to it this weekend.

This is related to #227.

[passcod]

While the root cause isn't yet fixed, 1.18.5 includes a fix which should help by relieving the pressure on the event channel.

[Mange]

How can I use #227 (I meant #254) to get around this? I can't figure it out.

It seems to me that there's a leak of inotify watchers, or too many watchers are set up.

> fd '.*\.rb' | wc -l
1032
> watchexec -e rb -- sleep 1

./bin/inotify-consumers

   INOTIFY
   WATCHES
    COUNT     PID USER     COMMAND
--------------------------------------
   35788   750356 mange    watchexec -e rb -- sleep 1

Is it walking down into my .git directory? It's not as easy as it watching all files recursively either.

> find . -type f | wc -l
89125

[passcod]

Yes, exactly so, it's recursing down every subdirectory regardless of them being ignored. 1.18.5 made that less likely to overwhelm the loop. #245 will add library capability to ignore or filter subdirectories, which could be used in the future to provide the direct control #227 wants, and will be used presently to stop recursing down paths which are ignored (including .git, output folders, etc).

As to your counts: try with the number of directories only? With inotify, that's what is watched.

[mikepqr]

My use case is a home directory containing a small number of directories and files that I do want to watch and a monorepo with hundreds of thousands of files that I do not want to watch.

Am I right in thinking this is not currently performant in watchexec because it sets up OS-level watchers on all files below the root, and filters out events on ignored paths as a post-processessing step, but that once #245 lands this use case will work well.

Is that about right? :-) (Happy to open a new issue for my use case if I've misunderstood this one!)

[passcod]

That's exactly right! You can do what you want with manual applications of -w for now, though.

[mikepqr]

Thanks! Looking forward to #245, because I don't think I can using -w is going to work for me. Please correct me if I'm wrong!

Essentially I have a tree that looks like this when I launch watchexec

.
├── bar/
├── foo.txt
└── ignoreme/
    └── baz.txt and 1000000s more files

I can't watch ignoreme/ (even if I discard the events), so I can't watch .. And a new directory might be created next to bar/ while watchexec is running, so enumerating the directories to watch with -w seems like it's not going to work.

[passcod]

Right, in this case, you can't use -w but #245 will work.