Daemon executing commands upon specified inotify-events.
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 1 week ago
manpages adding-recursion-to-inotify-detection 1 week ago
src adding-recursion-to-inotify-detection 1 week ago
systemd udpated service-file 2 weeks ago
tests master 1 week ago
.gitignore adding-recursion-to-inotify-detection 1 week ago
Cargo.lock master 6 months ago
Cargo.toml master 6 months ago
LICENSE master 6 months ago
README.md master 1 week ago

README.md

Thanks

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.

INOTIFY-DAEMON

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.

Example-Configuration

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
  action:
    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