Cookie file every minute

[nullromo]

I get these files showing up in my Downloads folder every minute and I don't know why. Are these generated by Watchman?

The files are named .watchman-cookie-<host>-506-<number>, where <host> is the name of my PC and <number> is a sequential number that starts at 0 every time I delete them all.

[jamie-phlo]

@nullromo did you ever figure out how to stop these being generated or pick a better folder for them to be in?

[nullromo]

Unfortunately the only solution I have right now is that I put this line in my .bashrc:

rm -v /mnt/c/Users/me/AppData/Roaming/wsltty/.watchman-cookie-hostname-* | tee >(wc -l); rm -v /mnt/c/Users/me/Downloads/.watchman-cookie-hostname-* | tee >(wc -l)

It's really annoying and hacky, but at least it works kinda. Still have no idea what thing on my computer even uses watchman...

[quark-zju]

watchman debug-status might show what are using watchman.

Those cookie files are generated on query by design and usually deleted by watchman automatically once it observes the cookie file creation event.

If you enable debug logs, then check the logs, it might show why the cookie files weren't deleted (like permission issues, or if there were an overflow of fsevents events).

[nullromo]

Thanks for the advice! I ran watchman debug-status and all I got was watchman: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory. I can't adjust the log level either.

I did find log files under /usr/local/var/run/watchman. There are a lot of permission denied errors in there that look like this

2022-11-14T15:25:20,874: [io 139660659530320 /home/kkovacs/oss_97542] getFileInformation(/home/kkovacs/oss_97542/src/components/userMembership.tsx) failed and not handled! -> Permission denied value=13 category=generic

The log goes back to 2022!

At the very bottom of the log, I see this

2025-03-11T14:44:58,282: [client=5:stm=140391743998576:pid=6357] send_error_response: ["get-pid"], failed: A non-recoverable condition has triggered.  Watchman needs your help!
The triggering condition was at timestamp=1741729442: opendir(/home/kkovacs/yocto/build/tmp/work/x86_64-linux/e2fsprogs-native/1.47.0/recipe-sysroot-native/usr/lib/perl5/5.38.2/unicore/lib/BidiM) -> The user limit on the total number of inotify watches was reached; increase the fs.inotify.max_user_watches sysctl
All requests will continue to fail with this message until you resolve
the underlying problem.  You will find more information on fixing this at
https://facebook.github.io/watchman/docs/troubleshooting.html#poison-opendir

2025-03-11T14:44:58,282: [sanitychecks] Failed to get pid from get-pid response: 
Fatal error detected at:
(error retrieving stack trace)

Following the instructions in the URL in that message leads to

$ watchman watch-del-all
$ watchman shutdown-server

However, I still get the error about loading libcrypto.so.1.1.

This stackoverflow answer made it work again.

Now I can run watchman debug-status. It prints a bunch of "ROOTS" like this:

/usr/local/lib/python3.10/dist-packages
  - fstype: ext4
  - watcher: inotify
  - uptime: 0 s
  - crawl_status: crawl completed 155ms ago, and took 12ms
  - done_initial: true

Not sure what this means though.

Anyway, then I was able to do watchman watch-del-all and watchman shutdown-server, then

$ watchman debug-status
ROOTS
-----
CLIENTS
-------
24950: 'watchman' 'debug-status'
  - since: 2025-03-12 12:10:16
  - state: dispatching command

So now all the "ROOTS" are gone. I guess maybe that means the problem will be solved (?) I will monitor this over the next few days and see if the files are coming back or not.