Is there a way to set something like a trigger on a file, so that everytime the file is changed a script or program will be executed?

I only found a mechanism for this within a shell script but would like to know if there is a mechanism for that on operating system basis (so that I don't have to manually run a background program). A solution on operating system basis would be a cron-job that runs every few seconds, but this does not look like an adequate solution to me.

It is for Debian, btw.

Thanks for help.

3 Answers 3


one of your options is the inotify subsystem of the linux kernel:

inotify is a Linux kernel subsystem that acts to extend filesystems to notice changes to the filesystem, and report those changes to applications

but since inotify is kernel-land, you need something in user-space to actually use it:

The inotify cron daemon (incrond) is a daemon which monitors filesystem events and executes commands defined in system and user tables. It's use is generally similar to cron(8).

Gamin is a monitoring system for files and directories that independently implements a subset of FAM, the File Alteration Monitor. Running as a service, it allows for the detection of modifications to a file or directory. gam_server functions as a daemon for Gamin.

inoticoming - trigger actions when files hit an incoming directory

there was an answer to a similar question on askubuntu:


  • 1
    Just to let you know: I now use inotify in combination with incron, which works perfectly fine for me. I'm aware that incron is still in alpha phase but it does a really well job. Thank you very much for this great advise!
    – cyphorious
    Dec 2, 2011 at 13:10

Another quick and dirty way to do this is to use inotifywait from the inotify-tools package (on fedora).

I like this method better because you can do it all from a single bash command line. I often use this when I'm writing small programs to see the results of what I just saved.

while [[ 1 ]]; do inotifywait -e modify <filename>; make && ./helloworld; done

I would argue that a mechanism for this within a shell script is a perfectly adequate solution and that a mechanism for that on operating system basis (so that I don't have to manually run a background program) just means putting that solution in a process manager like s6, runit, a systemd unit, or even an inittab entry if you're on a sysvinit system.

Regardless of the mechanism for keeping it running, I like entr for watching files. Simple, to the point, composable (e.g. trivial to put in a process manager).

Here's a script for watching /path/to/file and running /usr/local/bin/do_stuff when it changes:

exec entr /usr/local/bin/do_stuff < <(echo /path/to/file)

That's all there is to it. Put that in the run file of runit or s6, put it in the ExecStart line of a systemd unit, or call that script from a line in inittab. Although if you put it in inittab you probably want to add a sleep somewhere, as sysvinit doesn't rate-limit processes that fail immediately due to misspellings, missing files or such.

Why not just echo /path/to/file | entr /usr/local/bin/do_stuff? When running under process management, it's important for the managed process to be directly under the supervisor, so that it behaves correctly under e.g. shutdown. If the shell runs under the supervisor, the shell will catch any TERM, INT or KILL signals rather than the process it is running, and it won't pass them along. Or, it will exit and leave the process orphaned. exec removes the shell from the process chain. (exec on the right side of the | makes no difference)

Or just use a shell that never puts itself in the middle, execline:

pipeline -d {
  echo /path/to/file
} entr /usr/local/bin/do_stuff

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.