Linux inotify Monitor File system events __linux

1. Overview of the Inotify mechanism 1.1. Inotify Introduction

In day-to-day operations, you often need to back up some files, or to monitor certain files in your system, such as important configuration files. If you need to do real-time synchronization or monitoring, you need to use the kernel Inotify mechanism
Inotify is based on inode level of file system monitoring technology, is a powerful, fine-grained, asynchronous mechanism, It meets a wide range of file monitoring needs, not limited to security and performance
Inotify does not need to open a file descriptor for the target being monitored, and if the target is monitored on removable media, the watch of the monitored target will be deleted automatically after the file system is umount on the media. And a Umount event is generated. Inotify can either monitor files or monitor directories. Inotify uses system calls rather than Sigio to notify file system events. Inotify uses file descriptors as an interface, so you can monitor file system changes using the usual file I/O operations Select and poll. 1.2. Inotify file system events that can be monitored in_access: that is, files are accessed in_modify: Files are write In_attrib: file properties are modified, such as chmod, Chown, Touch In_close_write: Writable file is close in_close_nowrite: Cannot write file is close in_open: file is OPEN in_moved_from: file is moved, such as MV In_moved_to: Files are moved, such as MV, CP in_create: Create new files In_delete: Files are deleted, such as RM in_delete_self: From Delete, that is, an executable file deletes itself when executed in_move_self: self-moving, that is, an executable file in the hold In_unmount: The host file system is Umount in_close: file is closed, equivalent to (In_close_write | In_close_nowrite) In_move: File is moved, equivalent to (In_moved_from | IN_MOVED_TO)

Note: The file mentioned above also includes the directory 1.3. INotify Kernel version Support started with the kernel 2.6.13 , INotify formally merged into the kernel, RHEL5 has been supported. See if there is a/proc/sys/fs/inotify/directory to determine if the kernel supports inotify

  [Root@rhel5 rsync]# ls-l/proc/sys/fs/inotify/Total
  0
  -rw-r--r--1 root root 0 Oct  9 09:36 max_queued_events
  -rw-r--r--1 Root 0 Oct  9 09:36 max_user_instances
  -rw-r--r--1 root root 0 Oct  9 09:36 Max_user_wat Ches

default kernel parameters for 1.4. INotify/proc/sys/fs/inotify/max_queued_events Default value: 16384 The value in this file is the maximum value allocated to the number of event queues that can be queued in the INotify instance when the Inotify_init is invoked. Beyond this worthy event is discarded, but triggers the In_q_overflow event/proc/sys/fs/inotify/max_user_instances default value: 128 Specifies the inotify that each real user ID can create Instatnces Quantity Upper Limit/proc/sys/fs/inotify/max_user_watches Default value: 8192 specifies the upper limit of watches associated with each inotify instance

Note: max_queued_events is the maximum length of Inotify managed queues, and the more frequently the file system changes, the greater the value should be
if you see Event Queue Overflow in the log, Explains that max_queued_events is too small to be used again after adjusting the parameters. 2. Inotify in the system using the 2.1. Inotify Download Install inotify-tools source rhel5/centos5 rpm package under Linux shell Strong>inotifywait performs blocking only, waiting for inotify events. You can monitor any set of files and directories, or monitor the entire directory tree (directories, subdirectories, subdirectories of subdirectories, and so on)
use inotifywait in shell scripts. Inotifywatch collects statistics about the file systems being monitored, including how many times each inotify event occurs. Shell Script Example

  [Root@localhost]# cat/tmp/test.sh
  #!/bin/bash
  inotifywait-mrq--timefmt '%d/%m/%y%h:%m '--format '%T%w  %f%e '--event modify,delete,create,attrib  /home/admin | While the read  date Time file event does case
      $event I N
          modify| create| move| modify,isdir| create,isdir| Modify,isdir)
                  echo $event '-' $file
              ;;
  
          Moved_from| moved_from,isdir| delete| Delete,isdir)
                  echo $event '-' $file
              ;;
      Esac done
  

Execute script, result output (here test deletes a directory rm-fr Cronolog-1.6.2.bak)

  [root@localhost]#/tmp/test.sh delete-/home/admin/cronolog-1.6.2.bak/copying delete-/home/admin/ Cronolog-1.6.2.bak/doc/cronolog.info Delete-/home/admin/cronolog-1.6.2.bak/doc/cronolog.texi DELETE-/home/admin/ cronolog-1.6.2.bak/doc/makefile.am delete-/home/admin/cronolog-1.6.2.bak/doc/makefile.in DELETE-/home/admin/ Cronolog-1.6.2.bak/doc/texinfo.tex delete-/home/admin/cronolog-1.6.2.bak/doc/cronosplit.1m DELETE-/home/admin/ Cronolog-1.6.2.bak/doc/makefile delete-/home/admin/cronolog-1.6.2.bak/doc/cronolog.1m DELETE,ISDIR-/home/admin/ Cronolog-1.6.2.bak/doc Delete-/home/admin/cronolog-1.6.2.bak/todo delete-/home/admin/cronolog-1.6.2.bak/src/ Cronotest.c delete-/home/admin/cronolog-1.6.2.bak/src/cronolog.c delete-/home/admin/cronolog-1.6.2.bak/src/ Cronoutils.h DELETE-/HOME/ADMIN/CRONOLOG-1.6.2.BAK/SRC/CRONOUTILS.C delete-/home/admin/cronolog-1.6.2.bak/src/ makefile.am delete-/home/admin/cronolog-1.6.2.bak/src/makefile.in delete-/home/admin/cronolog-1.6.2. bak/src/cronosplit.in Delete-/home/admin/cronolog-1.6.2.bak/src/makefile delete-/home/admin/cronolog-1.6.2.bak/ Src/cronosplit delete-/home/admin/cronolog-1.6.2.bak/src/config.h delete,isdir-/home/admin/cronolog-1.6.2.bak/
  SRC delete-/home/admin/cronolog-1.6.2.bak/lib/getopt1.c delete-/home/admin/cronolog-1.6.2.bak/lib/getopt.h
  delete-/home/admin/cronolog-1.6.2.bak/lib/makefile.am delete-/home/admin/cronolog-1.6.2.bak/lib/makefile.in
  DELETE-/HOME/ADMIN/CRONOLOG-1.6.2.BAK/LIB/LOCALTIME_R.C delete-/home/admin/cronolog-1.6.2.bak/lib/getopt.c Delete-/home/admin/cronolog-1.6.2.bak/lib/makefile delete-/home/admin/cronolog-1.6.2.bak/lib/strptime.c DELETE, Isdir-/home/admin/cronolog-1.6.2.bak/lib Delete-/home/admin/cronolog-1.6.2.bak/config.cache DELETE-/home/admin/ Cronolog-1.6.2.bak/install-sh delete-/home/admin/cronolog-1.6.2.bak/makefile.am DELETE-/home/admin/ Cronolog-1.6.2.bak/readme delete-/home/admin/cronolog-1.6.2.bak/authors Delete-/home/admin/cronolOg-1.6.2.bak/makefile.in delete-/home/admin/cronolog-1.6.2.bak/testsuite/makefile.am DELETE-/home/admin/ Cronolog-1.6.2.bak/testsuite/readme delete-/home/admin/cronolog-1.6.2.bak/testsuite/makefile.in DELETE-/home/ Admin/cronolog-1.6.2.bak/testsuite/makefile Delete,isdir-/home/admin/cronolog-1.6.2.bak/testsuite DELETE-/home/ Admin/cronolog-1.6.2.bak/cronolog.spec delete-/home/admin/cronolog-1.6.2.bak/news DELETE-/home/admin/ Cronolog-1.6.2.bak/configure Delete-/home/admin/cronolog-1.6.2.bak/changelog DELETE-/home/admin/ Cronolog-1.6.2.bak/missing Delete-/home/admin/cronolog-1.6.2.bak/config.log delete-/home/admin/ CRONOLOG-1.6.2.BAK/ACLOCAL.M4 Delete-/home/admin/cronolog-1.6.2.bak/makefile DELETE-/home/admin/ Cronolog-1.6.2.bak/install Delete-/home/admin/cronolog-1.6.2.bak/config.status DELETE-/home/admin/ Cronolog-1.6.2.bak/configure.in Delete-/home/admin/cronolog-1.6.2.bak/mkinstalldirs DELETE,ISDIR-/home/admin/
 Cronolog-1.6.2.bak

Please refer to man inotify for details, man inotifywait 2.2. Implement critical profile monitoring using Incron

Incron is a inotify cron system that, like the OS itself, contains a daemon daemon (incrond) and an event editor (Incrontab
Unlike the OS's own cron, which only triggers time is the OS's operation on a file (folder) rather than time, the mechanism triggered by the system event, which is almost real-time for the application system. Install Incron Incron RPM Package

  [root@localhost]# Yum Install Incron

To view the types of events supported by Incron incrontab-t, edit the configuration file using the incrontab-eConfiguration file Format description (default configuration is in the/var/spool/incron/directory)

  <path> <mask> <command>

Option Description:
<path&gt: A file or directory that you want to monitor
<mask>:os events that occur to monitored objects
<command>:command can be a system command or a script, not a system redirect unless the redirection is written in the script. The following variables can also be used in <Command>:
$@: Representing <path&gt, the monitor object
$#: The object in which the system event occurred (for example, a folder was monitored and a file under it changed, then $ #就代表了该文件名)
$%: Represents <mask&gt, the event configuration that occurs:/home/admin/a.txt in_modify echo "$@ $#" means that once the file ABC is modified, it executes echo "$@ $#"/home/admin/in_all_events echo "$@ $# $%" indicates that a file under the directory triggers any event that executes echo "$@ $#"Start Incrond (/etc/init.d/incrond start), then delete ssss file in/home/admin directory, view Log Tail/var/log/cron, and have the following output

  Mar 14:05:19 localhost incrond[6857]: (Root) CMD (echo "/home/admin =  = In_open,in_isdir")
  Mar 14:05:19 Loca Lhost incrond[6857]: (Root) CMD (echo "/home/admin =  = In_close_nowrite,in_isdir")
  Mar-14:05:20 localhost incr Ond[6857]: (Root) CMD (echo "/home/admin =  = In_open,in_isdir")
  Mar 14:05:20 localhost incrond[6857]: (Root) CM D (echo "/home/admin =  = In_close_nowrite,in_isdir")
  Mar 14:05:20 localhost incrond[6857]: (Root) CMD (echo) Home/admin = SSSs = In_delete ")

In general, real-time monitoring of files and directories is still very effective and can be combined with other tools to unify the solution, such as using Syslog-ng for unified collection, of course, the most important thing is to have a scene.