Incron: Scheduling File System Event Handling

Introduction

Most Linux users are familiar with the convenient cron utility designed to plan and execute various operations at a specified time. But what if the action should be performed not at a certain point in time, but when a certain event occurs in the file system (for example, creating or deleting a file, changing the contents of a directory, etc.)? In this case, the incron software package may be useful.

Meet incron

The incron package is based on inotify , a Linux kernel subsystem that monitors file system changes and reports them to interested applications. The name of the program comes from the abbreviation and combination of the names of two subsystems: " IN otify CRON ".

By itself, the incron package is not very large, so it includes:

• daemon program ( incrond );
• a program that provides editing the event table ( incrontab );
• configuration file ( incron.conf );
• corresponding man pages.

You can download the incron package on the author’s website, Lukas Jelinek, or search the repositories of the Linux distribution you are using ( incron packages are available in the Fedora and Debian repositories ).

With the help of the incron package, you can solve a variety of tasks, starting with simple monitoring and collecting statistics on file system objects and notifying you of changes to configuration files or mailboxes. In more complex situations, incron can be used to protect important files from changes and automatically create backup copies when a specified set of files or directories change.

Use incron

Since incron is to some extent a “relative” of cron , the principles of using these programs and their user interface are also similar. Each user with rights to work with incron , refers to the program incrontab to view or edit the list of its rules (tasks). The demon program ( incrond ) processes these rules, and when an event specified in one of the rules occurs, it executes the corresponding command.

Use the incrontab -l command to view the current rule table, and the incrontab -e command to edit the rules. Editing is performed using a text editor defined in the EDITOR system variable. If you need to select another editor for working with the incrontab table without changing the EDITOR value, the following line should be entered into the /etc/incron.conf configuration file:

  editor = name of the required editor 

It should be remembered about the warning of the author of the program Lukas Elinika, who does not recommend using editors with a graphical interface (gvim, KEdit, gedit, etc.) due to possible problems with the interaction with the X-server. In this case, editors such as vim, emacs, nano, etc. are more preferable.

With the help of the incrontab -r command, a user can delete his current rule table, with no warnings or confirmation requests for deletion, so this command should be used with caution. After adding all necessary rules to the table, it can be saved in a file using the following command:

  incrontab -l & gt;  myincrontab.backup 

However, it will still be necessary to manually restore the rules if the table is deleted.

The incrond daemon responds immediately to changes to the rules and immediately reloads the edited table. But these changes will not affect commands that are already being executed at the moment. You can stop the current active incrond daemon using the following commands:

  incrond -k
   incrond --kill 

After installing the incron package, it can happen that none of the users (including the superuser root ) will have rights to work with the rules tables. In this case, you will need to add the names of the user accounts allowed to work with incron in the /etc/incron.allow file. Sometimes there are tips to remove the /etc/incron.allow file so that all local users get access to incron , but this step seems excessive and insecure (the author of the program himself admits this and intends to improve the access authorization in the next versions).

Format of rules (tasks) lines

The lines in the rules (tasks) table have the following syntax:

  <path_to_file> <event_flag_ mask> <command> 

• & lt; file_path & gt; - the best option would be to specify the full path to the monitored file or directory. If there are spaces in the path entry, then the backslash character ( \ ) must be specified before each space character.
• & lt; event_fask & gt; - character or numeric mask representing a combination of tracked events. When a mask is written symbolically, the flags of various events are separated from each other by commas.
• & lt; command & gt; - as with cron , the command can be the name of the executable file (program) or the name of the script that should be executed when the events specified by the mask occur.

Line items are separated from each other by an arbitrary number of spaces or tabs.

The mask may include flags of the events listed in table 1.

Table 1. List of events monitored by incron.

You can get a list of all event flags supported in the current version of incron using the following commands:

  incrontab -t
   incrontab - types 

After starting either of these two commands, a list of flags, separated by commas, will be sent to the standard output device.

As the author points out, the incrond daemon itself is not protected from the problem of infinite looping. That is, a situation is not excluded when some event initiated the execution of the corresponding command, which again leads to the occurrence of the same event, etc. (for example, the chmod command is used to process events of the IN_ATTRIB type.) The user must take protection against looping while processing events by writing the special flag IN_NO_LOOP to the mask. At the same time, all events for this rule are temporarily disabled until the current event is fully processed. After processing is completed, tracking of specified events will be automatically resumed. The disadvantage of this approach is the loss of those events that were generated in the interval when processing according to this rule was prohibited.

For convenience, the following templates may be included in the command specification:

• $ @ is the file system path that was specified in the rules table in the & lt; file_path & gt; ;
• $ # - the name of the file associated with the monitored event;
• $% - event flags presented in symbolic form;
• $ & amp; - the numeric value of the flag mask;
• $$ - to write the dollar symbol itself.

Incron usage examples

In some systems, documents for printing are not sent directly to the printer, but to a specially organized catalog of print jobs, called spooling. To track the appearance of tasks in the spooling in the incrontab, you can write a simple rule:

  / tmp / spool IN_CLOSE_WRITE / usr / local / bin / print_spool $ @ / $ # 

Now, after completing the recording and closing the file in the spool, the script will be initialized, allowing to print the specified file. The file name (with the full path to it) is passed to the script as an argument using the previously discussed templates.

If the superuser root is allowed to use incron , then you can back up configuration files with a history of changes (i.e., each file is labeled with a time stamp). To do this, "on behalf of" the root user , an incron_bckp.sh script is created (see Listing 1), which is located in the / usr / local / sbin directory.

Listing 1. Script for backing up modified configuration files

  #! / bin / sh
   mkdir -p / var / backup / incron
   # copying a modified file
   cp -p --parents $ 1 / var / backup / incron
   # rename copied file for time stamp
   mv / var / backup / incron $ 1 / var / backup / incron $ 1_`date +% Y-% m-% d_% H-% M-% S` 

This script must be made executable with the following command:

  chmod 755 /usr/local/sbin/incron_bckp.sh 

After that, you need to open the table of rules, as shown below:

  incrontab -e 

and add the following lines to it:

  / etc IN_CLOSE_WRITE, IN_MODIFY /usr/local/sbin/incron_bckp.sh $ @ / $ #
   / usr / etc IN_CLOSE_WRITE, IN_MODIFY /usr/local/sbin/incron_bckp.sh $ @ / $ #
   / usr / local / etc IN_CLOSE_WRITE, IN_MODIFY /usr/local/sbin/incron_bckp.sh $ @ / $ # 

After performing the specified actions, changes in the system configuration files will be recorded.

Sometimes there are situations in which you want to protect some file from changes after writing important information into it. For example, a critical warning is expected from a local mail service that should not be lost or erased by subsequent messages, etc. In this case, the operation of protecting a file from changes should be performed only once (after its completion, the corresponding incron rule loses meaning). To perform this task, you can create the following entry in incrontab :

  /home/alex/.mail.local/warning.msg IN_CLOSE_WRITE, IN_ONESHOT chmod $ 440 @ 

Conclusion

The incron service allows you to easily handle events that occur in the file system, and you can track events selectively, both for a single file and for a whole tree of subdirectories. The range of events monitored is quite wide: almost all possible variants of events in the file system are taken into account.

Installing The Package On Lenny / Sid

You should be able to:

  rt: ~ # apt-get install incron 

  rt: ~ # incrontab -l
 user 'root' is not allowed to use incron

This error may be fixed in one of two ways:

• Allow the user to make use of incron :
  • By editing /etc/incron.allow , adding 'root' to it.
• Allowing incron :
  • By removing the file /etc/incron.allow .

The IN_NO_LOOP parameter is EXTREMELY important in some cases and needs to be clarified, because incron itself does not have protection against looping. This parameter just allows you to avoid it, for example, in the case when we observe a file change , and we change its contents according to a certain rule, while monitoring is frozen until the end of the abcd command execution - there will be no looping.

The third rule follows the creation of new files and directories in the / home directory. (For example, this is almost always the case when registering new users). The program handler is specified with a full absolute path.

The last line shows the possibility of applying a numeric event mask. in this case, 12 corresponds to the events IN_ATTRIB, IN_CLOSE_WRITE.

I'd add that only one space is perceived as a separator in the lines of the configuration files, the incron responds incorrectly to a tab or several spaces by writing the error 'can not exec process: No such file or directory' to the syslog.