Due to infrastructure problems over the last 2 days(23/24.09.2020) Previous releases were lost. The code, however, is the same. Just in case you are wondering where the other tags went.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
ast 67a39b2f7c master 2 months ago
manpages adding-recursion-to-inotify-detection 2 months ago
src adding-recursion-to-inotify-detection 2 months ago
systemd udpated service-file 3 months ago
tests master 2 months ago
.gitignore adding-recursion-to-inotify-detection 2 months ago
Cargo.lock master 9 months ago
Cargo.toml master 9 months ago
LICENSE master 9 months ago
README.md master 2 months ago



Thanks are due to Hanno Braun and David Tolnay, the authors of https://github.com/inotify-rs/inotify and https://github.com/serde-rs/serde, for their wonderful pieces of software.

It made developing this piece of code easier.

Thanks also to the Rust-Community and their IRC, namely j`ey for easing the transition as I usually work in weakly typed, interpreted languages these days.


I hope you find this piece of code helpful. It is intended to react to file-events.

Frontend-developers have gulp, grunt, webpack with their logic or watchman, and IntelliJ uses their implementation.

But I have found a lack of potential automation when reacting to file-events for system-tasks.

e.g. automatically starting a script/binary if a new block-device is present, without having to implement the monitoring-logic as well.

Other use-cases would be monitoring of scripts for changes.

e.g. .php or .py/.pyc files are modified, added or deleted which will hint at an intrusion on a webhost.

A docker-container would not restart as it is kept alive by the interpreter/a daemon. Similar with Java (e.g. bytepatching).

So in this scenario, looking at the cotainer-fs(e.g. from the host (/var/lib/docker/...)) if a change is detected and it is not a deploy, notify staff, save container for post-mortem and restart container.

To trigger this logic you could use this piece of software.

It is ment to run as a service (e.g. systemd). It writes to stdout for the monitoring framework to log away.

Multiple actions per one entry are not specified, that aggregation will need to happen in the command. The result of the operation needs to be handled within the action as well as inotify_daemon does not know the propper default behaviour.


Following configuration listens to creations(mode: c) in path ./tests/test_working_dir/dir_watched. It then executes command rm with parameters “-f” and “./tests/test_working_dir/creation_witnessed” .

- path: ./tests/test_working_dir/dir_watched
    command: rm
    parameter: ["-f", "./tests/test_working_dir/creation_witnessed"] 
  mode: C

Paths can be relative to the working-directory or absolute. Parameters for commands to be executed are optional, the command is not. Mode is also optional, if it is not specified, or an unknown mode is specified, it will listen to all events. Supported modes are: “M” => modify, “C” => create, “SD” => delete-self, “D” => delete, “O” => open

Additional parameters that can be passed to the script are:

  • file name with :@file_name@: <- the name of the file, can also be "”
  • file directory with :@file_directory@: <- the directory that is being watched
  • file path with :@file_path@: <- the FQN of the file, this is directory + file_name