Closed paulraines68 closed 1 year ago
Hi Paul. Do you think a config file of some sort that has a list of directories to ignore would be the best way to handle this? Thanks!
Yes, that would be the most managable way
Can you try the latest version when you get a chance? This commit:
Use via config file. Something like:
cat /home/mikesart/inotify-info.config
/ignore/dir/1
/ignore/dir/2
And also via command line argument:
inotify-info --ignoredir "/ignore/dir/3"
Add '-vv' arg to list ignored directories
For the file, it should check $HOME/inotify-info.config, $XDG_CONFIG_HOME/inotify-info.config, $XDG_CONFIG_HOME/.config/inotify-info.config
I haven't tested a ton so let me know if you run into any issues. Thanks.
It seems to work. Thanks
I would say the format of the config file should be something like:
ignoredir=/ignore/dir/3
Also, looking for /etc/inotify-info.config as well in the list would be nice
Seems also I cannot build on RHEL7 (complains about statx undefined) anymore, but builds fine on RHEL8
Can I ask why you think the format should be key/value pairs as opposed to just value. Just not sure what use the value part is. And I can add /etc/inotify-info.config checking.
The RHEL7 will be a larger issue. I don’t believe the older version of the kernel they’re using supports the syscall.
In case other configuration directives come about that will go in the config file and a key will be needed to differentiate
Added check for /etc/inotify-info.config and ignore directories should be listed under a "[ignoredirs]" section. Ie:
[ignoredirs]
/ignore/dir/1
/ignore/dir/2
Seems also I cannot build on RHEL7 (complains about statx undefined) anymore, but builds fine on RHEL8
I just pushed a commit that should fall back to using stat
on older systems. Haven't tested it yet since I'm on vacation in Iceland at the moment but if you get a chance could you give it a try and let me know how it goes? Thanks!
Works fine. Compiled and tested on a RHEL7 box. Thanks
Curious issue I just found. If I give as a final argument (because of mistype) a service app name that does not match one given is the list from just running inotify-info by itself, instead of an error message it just acts like that service app name was not given at all
It works where you can list multiple app names and/or pids to do matches on. Kinda like ps does with the -q argument when the pid doesn't actually exist.
mikesart@mikesart-falcon:/mnt/d/dev/inotify-info.git$ ps -e
PID TTY TIME CMD
1 ? 00:00:00 init(Debian)
4 ? 00:00:00 init
58 ? 00:00:00 SessionLeader
59 ? 00:00:00 Relay(60)
60 pts/0 00:00:00 bash
15082 pts/0 00:00:00 ps
mikesart@mikesart-falcon:/mnt/d/dev/inotify-info.git$ ps -q 1,4,100,128
PID TTY TIME CMD
1 ? 00:00:00 init(Debian)
4 ? 00:00:00 init
When I first ran this as 'inotify-info splunkd' to see what splunk was watching, it was taking over four hours before I just killed it. I then found out it was crawling down my automount mount points and my maps have over 1000 entries. Not sure if there is a way to make it avoid crawling down automount mounts that are not mounted yet.
For my purposes I am only interested in finding watches on the local, non-data filesystems so I modified parse_dirqueue_entry() at the beginning to avoid my paths used for automounting and large local data volumes with lines like