使用 inotify 的 Linux 文件系统事件

于 2018 年 1 月 8 日

使用 incron 和 systemd 触发脚本。

有时，了解 Linux 操作系统中的更改非常重要。系统的用途通常包括必须在看到后立即处理的高优先级数据。查找和处理新文件数据的传统方法是轮询，通常使用 cron。这种方法效率低下，如果过于频繁地 fork 过多的轮询事件，可能会不合理地增加性能负担。

Linux 提供了一种高效的方法来提醒用户空间进程注意影响感兴趣文件的更改。inotify Linux 系统调用最初在Linux Journal 的 2005 年 Robert Love 的文章中被讨论，该文章主要从 C 的角度探讨了新功能的行为。

然而，也有稳定的 shell 级实用程序和新型监控守护程序，用于注册文件系统监视和报告事件。使用 systemd 的 Linux 安装也可以通过路径单元访问基本的 inotify 功能。inotify 接口确实存在局限性——它无法监控远程、网络挂载的文件系统（即 NFS）；它不报告事件中涉及的用户 ID；它不适用于 /proc 或其他伪文件系统；并且 mmap() 操作不会触发它，以及其他一些问题。即使存在这些限制，它仍然是一个非常有用的功能。

本文完成了 Love 开始的工作，并使每个能够编写 Bourne shell 脚本或设置 crontab 的人都有能力对文件系统更改做出反应。

inotifywait 实用程序

在 Oracle Linux 7（或类似版本的 Red Hat/CentOS/Scientific Linux）下工作，默认情况下未安装 inotify shell 工具，但您可以使用 yum 加载它们


 # yum install inotify-tools
Loaded plugins: langpacks, ulninfo
ol7_UEKR4                                      | 1.2 kB   00:00
ol7_latest                                     | 1.4 kB   00:00
Resolving Dependencies
--> Running transaction check
---> Package inotify-tools.x86_64 0:3.14-8.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================
Package         Arch       Version        Repository     Size
==============================================================
Installing:
inotify-tools   x86_64     3.14-8.el7     ol7_latest     50 k

Transaction Summary
==============================================================
Install  1 Package

Total download size: 50 k
Installed size: 111 k
Is this ok [y/d/N]: y
Downloading packages:
inotify-tools-3.14-8.el7.x86_64.rpm               |  50 kB   00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.
  Installing : inotify-tools-3.14-8.el7.x86_64                 1/1
  Verifying  : inotify-tools-3.14-8.el7.x86_64                 1/1

Installed:
  inotify-tools.x86_64 0:3.14-8.el7

Complete!

该软件包将包含两个实用程序（inotifywait 和 inotifywatch）、文档和许多库。inotifywait 程序是主要关注点。

Red Hat 7 的某些衍生版本可能在其基本存储库中不包含 inotify。如果您发现它缺失，您可以从 Fedora 的 EPEL 存储库中获取它，方法是下载 inotify RPM 进行手动安装，或者将 EPEL 存储库添加到 yum。

系统上任何可以启动 shell 的用户都可以注册监视——使用该接口不需要特殊权限。此示例监视 /tmp 目录


$ inotifywait -m /tmp
Setting up watches.
Watches established.

如果系统上的另一个会话对 /tmp 中的文件执行一些操作


$ touch /tmp/hello
$ cp /etc/passwd /tmp
$ rm /tmp/passwd
$ touch /tmp/goodbye
$ rm /tmp/hello /tmp/goodbye

正在运行 inotifywait 的用户可以立即看到这些更改


/tmp/ CREATE hello
/tmp/ OPEN hello
/tmp/ ATTRIB hello
/tmp/ CLOSE_WRITE,CLOSE hello
/tmp/ CREATE passwd
/tmp/ OPEN passwd
/tmp/ MODIFY passwd
/tmp/ CLOSE_WRITE,CLOSE passwd
/tmp/ DELETE passwd
/tmp/ CREATE goodbye
/tmp/ OPEN goodbye
/tmp/ ATTRIB goodbye
/tmp/ CLOSE_WRITE,CLOSE goodbye
/tmp/ DELETE hello
/tmp/ DELETE goodbye

手册页的一些相关部分解释了正在发生的事情


$ man inotifywait | col -b | sed -n '/diagnostic/,/helpful/p'
  inotifywait will output diagnostic information on standard error and
  event information on standard output. The event output can be config-
  ured, but by default it consists of lines of the following form:

  watched_filename EVENT_NAMES event_filename


  watched_filename
    is the name of the file on which the event occurred. If the
    file is a directory, a trailing slash is output.

  EVENT_NAMES
    are the names of the inotify events which occurred, separated by
    commas.

  event_filename
    is output only when the event occurred on a directory, and in
    this case the name of the file within the directory which caused
    this event is output.

    By default, any special characters in filenames are not escaped
    in any way. This can make the output of inotifywait difficult
    to parse in awk scripts or similar. The --csv and --format
    options will be helpful in this case.

也可以通过使用 -e 选项注册特定的感兴趣事件来过滤输出，事件列表如下所示

access	create	move_self
attrib	delete	moved_to
close_write	delete_self	moved_from
close_nowrite	modify	open
close	move	unmount

一个常见的应用是测试新文件的到达。由于 inotify 必须给定要监视的现有文件系统对象的名称，因此提供了包含新文件的目录。感兴趣的触发器也很容易提供——当 close_write 触发器触发时，新文件应该已完成并准备好进行处理。以下是监视这些事件的示例脚本


#!/bin/sh
unset IFS                                 # default of space, tab and nl
                                          # Wait for filesystem events
inotifywait -m -e close_write \
   /tmp /var/tmp /home/oracle/arch-orcl/ |
while read dir op file
do [[ "${dir}" == '/tmp/' && "${file}" == *.txt ]] &&
      echo "Import job should start on $file ($dir $op)."

   [[ "${dir}" == '/var/tmp/' && "${file}" == CLOSE_WEEK*.txt ]] &&
      echo Weekly backup is ready.

   [[ "${dir}" == '/home/oracle/arch-orcl/' && "${file}" == *.ARC ]]
&&
      su - oracle -c 'ORACLE_SID=orcl ~oracle/bin/log_shipper' &

   [[ "${dir}" == '/tmp/' && "${file}" == SHUT ]] && break

   ((step+=1))
done

echo We processed $step events.

所提供的脚本存在一些问题——在 Linux 上所有可用的 shell 中，只有 ksh93（即 AT&T Korn shell）会在脚本末尾正确报告“step”变量。所有其他 shell 都会将此变量报告为空。

此行为的原因可以在 Bash 的手册页上的简要说明中找到：“管道中的每个命令都作为单独的进程（即，在子 shell 中）执行。” MirBSD 克隆的 Korn shell 有稍微更长的解释


# man mksh | col -b | sed -n '/The parts/,/do so/p'
  The parts of a pipeline, like below, are executed in subshells. Thus,
  variable assignments inside them fail. Use co-processes instead.

  foo | bar | read baz          # will not change $baz
  foo | bar |& read -p baz      # will, however, do so

并且，Oracle Linux 5 中的 pdksh 文档（MirBSD mksh 从中衍生而来）对该主题有更多提及


General features of at&t ksh88 that are not (yet) in pdksh:
  - the last command of a pipeline is not run in the parent shell
  - `echo foo | read bar; echo $bar' prints foo in at&t ksh, nothing
    in pdksh (ie, the read is done in a separate process in pdksh).
  - in pdksh, if the last command of a pipeline is a shell builtin, it
    is not executed in the parent shell, so "echo a b | read foo bar"
    does not set foo and bar in the parent shell (at&t ksh will).
    This may get fixed in the future, but it may take a while.

$ man pdksh | col -b | sed -n '/BTW, the/,/aware/p'
  BTW, the most frequently reported bug is
    echo hi | read a; echo $a   # Does not print hi
  I'm aware of this and there is no need to report it.

此行为很容易演示——使用默认 bash shell 运行上述脚本并提供一系列示例事件


$ cp /etc/passwd /tmp/newdata.txt
$ cp /etc/group /var/tmp/CLOSE_WEEK20170407.txt
$ cp /etc/passwd /tmp/SHUT

给出以下脚本输出


# ./inotify.sh
Setting up watches.
Watches established.
Import job should start on newdata.txt (/tmp/ CLOSE_WRITE,CLOSE).
Weekly backup is ready.
We processed events.

在脚本运行时检查进程列表，您还会看到两个 shell，一个为控制结构 fork 的 shell


$ function pps { typeset a IFS=\| ; ps ax | while read a
do case $a in *$1*|+([!0-9])) echo $a;; esac; done }


$ pps inot
  PID TTY      STAT   TIME COMMAND
 3394 pts/1    S+     0:00 /bin/sh ./inotify.sh
 3395 pts/1    S+     0:00 inotifywait -m -e close_write /tmp /var/tmp
 3396 pts/1    S+     0:00 /bin/sh ./inotify.sh

由于 “step” 变量在子 shell 中被操作，因此当控制流到达 echo 时，它为空。将 #/bin/sh 切换为 #/bin/ksh93 将纠正此问题，并且只会看到一个 shell 进程


# ./inotify.ksh93
Setting up watches.
Watches established.
Import job should start on newdata.txt (/tmp/ CLOSE_WRITE,CLOSE).
Weekly backup is ready.
We processed 2 events.


$ pps inot
  PID TTY      STAT   TIME COMMAND
 3583 pts/1    S+     0:00 /bin/ksh93 ./inotify.sh
 3584 pts/1    S+     0:00 inotifywait -m -e close_write /tmp /var/tmp

尽管 ksh93 行为正确，并且通常比所有其他 Linux shell 更优雅地处理脚本，但它相当大


$ ll /bin/[bkm]+([aksh93]) /etc/alternatives/ksh
-rwxr-xr-x. 1 root root  960456 Dec  6 11:11 /bin/bash
lrwxrwxrwx. 1 root root      21 Apr  3 21:01 /bin/ksh ->
                                               /etc/alternatives/ksh
-rwxr-xr-x. 1 root root 1518944 Aug 31  2016 /bin/ksh93
-rwxr-xr-x. 1 root root  296208 May  3  2014 /bin/mksh
lrwxrwxrwx. 1 root root      10 Apr  3 21:01 /etc/alternatives/ksh ->
                                                    /bin/ksh93

mksh 二进制文件是上述 Bourne 实现中最小的（您的系统上可能缺少其中一些 shell，但您可以使用 yum 安装它们）。对于长期监控进程，mksh 可能是降低处理和内存占用量的最佳选择，并且在假设使用协进程的情况下，它在空闲时不会启动自身的多个副本。将脚本转换为使用对 mksh 友好的 Korn 协进程并不困难


#!/bin/mksh
unset IFS                              # default of space, tab and nl
                                       # Wait for filesystem events
inotifywait -m -e close_write \
   /tmp/ /var/tmp/ /home/oracle/arch-orcl/ \
   2</dev/null |&                      # Launch as Korn coprocess

while read -p dir op file              # Read from Korn coprocess
do [[ "${dir}" == '/tmp/' && "${file}" == *.txt ]] &&
      print "Import job should start on $file ($dir $op)."

   [[ "${dir}" == '/var/tmp/' && "${file}" == CLOSE_WEEK*.txt ]] &&
      print Weekly backup is ready.

   [[ "${dir}" == '/home/oracle/arch-orcl/' && "${file}" == *.ARC ]]
&&
      su - oracle -c 'ORACLE_SID=orcl ~oracle/bin/log_shipper' &

   [[ "${dir}" == '/tmp/' && "${file}" == SHUT ]] && break

   ((step+=1))
done

echo We processed $step events.

请注意，关于 Korn shell 的 Korn 和 Bolsky 参考资料概述了作为协进程运行的程序中的以下要求

注意：协进程必须

将每个输出消息发送到标准输出。

在每条消息的末尾都有一个换行符。

每当它写入消息时，刷新其标准输出。

在 inotifywait 源代码的主处理循环中找到了 fflush(NULL)，并且这些要求似乎已得到满足。

mksh 版本的脚本是高效使用和正确行为之间最合理的折衷方案，我在这里详细解释它以节省读者麻烦和挫败感——在大多数 Borne 系列中，避免在子 shell 中执行控制结构非常重要。但是，希望所有这些 ersatz shell 将来有一天能够修复这个基本缺陷并正确实现 Korn 行为。

实际应用——Oracle 日志传输

配置为热备份的 Oracle 数据库会生成“归档重做日志文件”流，这些文件用于数据库恢复。这些是在 Oracle 数据库中生成的最关键的备份文件。

这些文件按顺序编号，并写入 DBA 配置的日志目录。inotifywatch 可以触发活动，以压缩、加密和/或将归档日志分发到备份和灾难恢复服务器以进行安全保管。您可以配置 Oracle RMAN 来执行这些功能中的大多数，但操作系统工具功能更强大、更灵活且更易于使用。

处理归档日志的脚本有许多重要的设计参数

必须建立一个“临界区”，该临界区只允许单个进程一次操作归档日志文件。Oracle 有时会写入突发的日志文件，inotify 可能会导致处理程序脚本在短时间内重复生成。只允许运行处理程序脚本的一个实例——在处理程序的生命周期内生成的任何其他实例都必须立即退出。这将通过教科书式的 flock 程序（来自 util-linux 软件包）的应用来实现。
生产应用程序可用的最佳压缩似乎是 lzip。作者声称，他的归档格式的完整性优于许多更知名的实用程序，无论是在压缩能力还是结构完整性方面。lzip 二进制文件不在 Oracle Linux 的标准存储库中——它在 EPEL 中可用，并且很容易从源代码编译。
请注意，7-Zip 使用与 lzip 相同的 LZMA 算法，并且它还将在压缩后对数据执行 AES 加密。加密是一项理想的功能，因为它将使企业免受美国大多数州的违规披露法律的约束，如果备份丢失或被盗，并且它们包含“受保护的个人信息”（PPI），例如生日或社会安全号码。lzip 的作者确实对使用 LZMA2 的 7-Zip 归档文件的质量发表了严厉的批评，并且可以使用 openssl enc 程序在压缩后对 lzip 归档文件或任何其他类型的文件应用 AES 加密，正如我在之前的文章中讨论的那样。我在下面的脚本中省略了文件加密，并使用 lzip 以使其清晰明了。
当前日志编号将记录在 Oracle 用户主目录下的点文件中。如果由于某种原因跳过了日志（对于 Oracle 数据库来说很少发生），日志传输将停止。丢失日志需要立即进行完整数据库备份（冷备份或热备份）——Oracle 数据库的成功恢复不能跳过日志。
scp 程序将用于将日志复制到远程服务器，应重复调用它直到它成功返回。
我正在为这项活动调用真正的 '93 Korn shell，因为它是功能最强大的脚本 shell，我不希望有任何意外。

给定这些设计参数，这是一个实现


# cat ~oracle/archutils/process_logs

#!/bin/ksh93

set -euo pipefail
IFS=$'\n\t'  # http://redsymbol.net/articles/unofficial-bash-strict-mode/

(
 flock -n 9 || exit 1          # Critical section-allow only one process.

 ARCHDIR=~oracle/arch-${ORACLE_SID}

 APREFIX=${ORACLE_SID}_1_

 ASUFFIX=.ARC

 CURLOG=$(<~oracle/.curlog-$ORACLE_SID)

 File="${ARCHDIR}/${APREFIX}${CURLOG}${ASUFFIX}"

 [[ ! -f "$File" ]] && exit

 while [[ -f "$File" ]]
 do ((NEXTCURLOG=CURLOG+1))

    NextFile="${ARCHDIR}/${APREFIX}${NEXTCURLOG}${ASUFFIX}"

    [[ ! -f "$NextFile" ]] && sleep 60  # Ensure ARCH has finished

    nice /usr/local/bin/lzip -9q "$File"

    until scp "${File}.lz" "yourcompany.com:~oracle/arch-$ORACLE_SID"
    do sleep 5
    done

    CURLOG=$NEXTCURLOG

    File="$NextFile"
 done

 echo $CURLOG > ~oracle/.curlog-$ORACLE_SID

) 9>~oracle/.processing_logs-$ORACLE_SID

即使在 inotify 处理程序运行时，也可以手动执行上述脚本进行测试，因为 flock 会保护它。

备用服务器或处于原始备用模式下的 DataGuard 服务器可以定期应用归档日志。以下脚本强制日志应用程序延迟 12 小时，以便恢复删除或损坏的对象，因此在这种情况下 inotify 不易使用——cron 对于延迟文件处理是一种更合理的方法，并且每 20 分钟运行一次将使备用服务器保持在所需的恢复点


# cat ~oracle/archutils/delay-lock.sh

#!/bin/ksh93

(
 flock -n 9 || exit 1              # Critical section-only one process.

 WINDOW=43200                      # 12 hours

 LOG_DEST=~oracle/arch-$ORACLE_SID

 OLDLOG_DEST=$LOG_DEST-applied

 function fage { print $(( $(date +%s) - $(stat -c %Y "$1") ))
  } # File age in seconds - Requires GNU extended date & stat

 cd $LOG_DEST

 of=$(ls -t | tail -1)             # Oldest file in directory

 [[ -z "$of" || $(fage "$of") -lt $WINDOW ]] && exit

 for x in $(ls -rt)                    # Order by ascending file mtime
 do if [[ $(fage "$x") -ge $WINDOW ]]
    then y=$(basename $x .lz)          # lzip compression is optional

         [[ "$y" != "$x" ]] && /usr/local/bin/lzip -dkq "$x"

         $ORACLE_HOME/bin/sqlplus '/ as sysdba' > /dev/null 2>&1 <<-EOF
                recover standby database;
                $LOG_DEST/$y
                cancel
                quit
                EOF

         [[ "$y" != "$x" ]] && rm "$y"

         mv "$x" $OLDLOG_DEST
    fi
              

 done
) 9> ~oracle/.recovering-$ORACLE_SID

我在这里介绍了这些具体示例，因为它们引入了控制并发性的工具，这是使用 inotify 时的常见问题，并且它们推进了一些提高可靠性并最大限度减少存储需求的功能。希望热情的读者将对这些方法进行许多改进。

incron 系统

Lukas Jelinek 是 incron 软件包的作者，该软件包允许用户指定由主 incrond 进程执行的 inotify 事件表。尽管提到了 “cron”，但该软件包不会按固定时间间隔调度事件——它是一个用于文件系统事件的工具，并且对 cron 的引用略有误导性。

incron 软件包可从 EPEL 获得。如果您已安装存储库，则可以使用 yum 加载它


# yum install incron
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package incron.x86_64 0:0.5.10-8.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=================================================================
 Package       Arch       Version           Repository    Size
=================================================================
Installing:
 incron        x86_64     0.5.10-8.el7      epel          92 k

Transaction Summary
==================================================================
Install  1 Package

Total download size: 92 k
Installed size: 249 k
Is this ok [y/d/N]: y
Downloading packages:
incron-0.5.10-8.el7.x86_64.rpm                      |  92 kB   00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : incron-0.5.10-8.el7.x86_64                          1/1
  Verifying  : incron-0.5.10-8.el7.x86_64                          1/1

Installed:
  incron.x86_64 0:0.5.10-8.el7

Complete!

在具有适当服务单元的 systemd 发行版上，您可以使用以下命令在启动时启动并启用 incron


# systemctl start incrond
# systemctl enable incrond
Created symlink from
   /etc/systemd/system/multi-user.target.wants/incrond.service
to /usr/lib/systemd/system/incrond.service.

在默认配置中，任何用户都可以建立 incron 计划。incrontab 格式使用三个字段


<path> <mask> <command>

以下是使用 -e 选项设置的示例条目


$ incrontab -e        #vi session follows

$ incrontab -l
/tmp/ IN_ALL_EVENTS /home/luser/myincron.sh $@ $% $#

您可以记录一个简单的脚本并将其标记为可执行权限


$ cat myincron.sh
#!/bin/sh

echo -e "path: $1 op: $2 \t file: $3" >> ~/op

$ chmod 755 myincron.sh

然后，如果您重复本文开头处的原始 /tmp 文件操作，脚本将记录以下输出


$ cat ~/op

path: /tmp/ op: IN_ATTRIB        file: hello
path: /tmp/ op: IN_CREATE        file: hello
path: /tmp/ op: IN_OPEN          file: hello
path: /tmp/ op: IN_CLOSE_WRITE   file: hello
path: /tmp/ op: IN_OPEN          file: passwd
path: /tmp/ op: IN_CLOSE_WRITE   file: passwd
path: /tmp/ op: IN_MODIFY        file: passwd
path: /tmp/ op: IN_CREATE        file: passwd
path: /tmp/ op: IN_DELETE        file: passwd
path: /tmp/ op: IN_CREATE        file: goodbye
path: /tmp/ op: IN_ATTRIB        file: goodbye
path: /tmp/ op: IN_OPEN          file: goodbye
path: /tmp/ op: IN_CLOSE_WRITE   file: goodbye
path: /tmp/ op: IN_DELETE        file: hello
path: /tmp/ op: IN_DELETE        file: goodbye

虽然目录对象上的 IN_CLOSE_WRITE 事件通常最受关注，但大多数标准 inotify 事件在 incron 中都可用，incron 还提供了一些独特的混合


$ man 5 incrontab | col -b | sed -n '/EVENT SYMBOLS/,/child process/p'

EVENT SYMBOLS

These basic event mask symbols are defined:

IN_ACCESS          File was accessed (read) (*)
IN_ATTRIB          Metadata changed (permissions, timestamps, extended
                   attributes, etc.) (*)
IN_CLOSE_WRITE     File opened for writing was closed (*)
IN_CLOSE_NOWRITE   File not opened for writing was closed (*)
IN_CREATE          File/directory created in watched directory (*)
IN_DELETE          File/directory deleted from watched directory (*)
IN_DELETE_SELF     Watched file/directory was itself deleted
IN_MODIFY          File was modified (*)
IN_MOVE_SELF       Watched file/directory was itself moved
IN_MOVED_FROM      File moved out of watched directory (*)
IN_MOVED_TO        File moved into watched directory (*)
IN_OPEN            File was opened (*)

When monitoring a directory, the events marked with an asterisk (*)
above can occur for files in the directory, in which case the name
field in the returned event data identifies the name of the file within
the directory.

The IN_ALL_EVENTS symbol is defined as a bit mask of all of the above
events. Two additional convenience symbols are IN_MOVE, which is a com-
bination of IN_MOVED_FROM and IN_MOVED_TO, and IN_CLOSE, which combines
IN_CLOSE_WRITE and IN_CLOSE_NOWRITE.

The following further symbols can be specified in the mask:

IN_DONT_FOLLOW     Don't dereference pathname if it is a symbolic link
IN_ONESHOT         Monitor pathname for only one event
IN_ONLYDIR         Only watch pathname if it is a directory

Additionally, there is a symbol which doesn't appear in the inotify sym-
bol set. It is IN_NO_LOOP. This symbol disables monitoring events until
the current one is completely handled (until its child process exits).

对于那些需要非标准配置的用户，incron 系统可能是此处研究和列出的所有工具中 inotify 最全面的接口。可以在 /etc/incron.conf 中设置其他配置选项，以调整 incron 的行为。

systemd 下的路径单元

当您的 Linux 安装运行 systemd 作为 PID 1 时，可以通过 “路径单元” 获得有限的 inotify 功能，正如 Paul Brown 在 OCS-Mag 上的一篇轻松的文章中讨论的那样。

相关的手册页包含有关该主题的有用信息


$ man systemd.path | col -b | sed -n '/Internally,/,/systems./p'

Internally, path units use the inotify(7) API to monitor file systems.
Due to that, it suffers by the same limitations as inotify, and for
example cannot be used to monitor files or directories changed by other
machines on remote NFS file systems.

请注意，当 systemd 路径单元生成 shell 脚本时，所有者的主目录的 $HOME 和波浪号 (~) 运算符可能未定义。使用波浪号运算符引用另一个用户的主目录（例如，~nobody/）确实有效，即使应用于运行脚本的同一用户也是如此。上面的 Oracle 脚本是显式的，并且在未指定目标用户的情况下没有引用 ~，因此我在这里将其用作示例。

将 inotify 触发器与 systemd 路径单元一起使用需要两个文件。第一个文件指定感兴趣的文件系统位置


$ cat /etc/systemd/system/oralog.path

[Unit]
Description=Oracle Archivelog Monitoring
Documentation=http://docs.yourserver.com

[Path]
PathChanged=/home/oracle/arch-orcl/

[Install]
WantedBy=multi-user.target

上面的 PathChanged 参数大致对应于我之前直接 inotify 调用中使用的 close-write 事件。systemd（目前）不支持完整的 inotify 事件集合——它仅限于 PathExists、PathChanged 和 PathModified，这些事件在 man systemd.path 中进行了描述。

第二个文件是描述要执行的程序的服务单元。它必须具有相同的名称，但扩展名不同，与路径单元相同


$ cat /etc/systemd/system/oralog.service

[Unit]
Description=Oracle Archivelog Monitoring
Documentation=http://docs.yourserver.com

[Service]
Type=oneshot
Environment=ORACLE_SID=orcl
ExecStart=/bin/sh -c '/root/process_logs >> /tmp/plog.txt 2>&1'

上面的 oneshot 参数警告 systemd，它 fork 的程序预计会退出，并且不应自动重新生成——重新启动仅限于来自路径单元的触发器。上面的服务配置将为日志记录提供最佳选项——如果不需要日志记录，请将它们转移到 /dev/null。

在路径单元上使用 systemctl start 开始监控——一个常见的错误是在服务单元上使用它，这将仅直接运行处理程序一次。如果监控应在重启后继续存在，请启用路径单元。

尽管这种有限的功能可能足以满足 inotify 的某些临时用途，但令人遗憾的是，inotifywait 和 incron 的全部功能并未在此处体现出来。也许随着时间的推移会实现。

结论

尽管 inotify 工具功能强大，但它们确实存在局限性。重复一下，inotify 无法监控远程 (NFS) 文件系统；它无法报告触发事件中涉及的用户 ID；它不适用于 /proc 或其他伪文件系统；mmap() 操作不会触发它；并且 inotify 队列可能会溢出，从而导致事件丢失，以及其他一些问题。

即使存在这些弱点，inotify 的效率也优于大多数其他用于立即通知文件系统活动的方法。它也非常灵活，虽然 close-write 目录触发器应该足以满足大多数用途，但它也拥有充足的工具来涵盖特殊用例。

在任何情况下，用 inotify 监视替换轮询活动都是富有成效的，系统管理员应该广泛教育用户社区，经典的 crontab 不是检查新文件的合适场所。顽固的用户应该被限制在 VAX 上的 Ultrix 中，直到他们对现代工具和方法产生足够的欣赏，这应该会提高 Linux 系统的效率，并使管理员更快乐。

旁注：归档 /etc/passwd

跟踪密码文件的更改涉及许多不同类型的 inotify 触发事件。vipw 实用程序通常会对临时文件进行更改，然后用它覆盖原始文件。当 inode 编号更改时，可以看到这一点


# ll -i /etc/passwd
199720973 -rw-r--r-- 1 root root 3928 Jul  7 12:24 /etc/passwd

# vipw
[ make changes ]
You are using shadow passwords on this system.
Would you like to edit /etc/shadow now [y/n]? n

# ll -i /etc/passwd
203784208 -rw-r--r-- 1 root root 3956 Jul  7 12:24 /etc/passwd

即使是未特权用户调用的 setuid 二进制文件也会发生 /etc/passwd 的销毁和替换


$ ll -i /etc/passwd
203784196 -rw-r--r-- 1 root root 3928 Jun 29 14:55 /etc/passwd

$ chsh
Changing shell for fishecj.
Password:
New shell [/bin/bash]: /bin/csh
Shell changed.

$ ll -i /etc/passwd
199720970 -rw-r--r-- 1 root root 3927 Jul  7 12:23 /etc/passwd

因此，在跟踪此文件时，应考虑所有 inotify 触发事件。如果担心 inotify 队列溢出（其中事件丢失），则 OPEN、ACCESS 和 CLOSE_NOWRITE,CLOSE 触发器可能会立即被忽略。

/etc/passwd 上的所有其他 inotify 事件可能会运行以下脚本，以将更改版本化到 RCS 归档中并将其邮寄给管理员


#!/bin/sh

# This script tracks changes to the /etc/passwd file from inotify.
# Uses RCS for archiving. Watch for UID zero.

PWMAILS=Charlie.Root@openbsd.org

TPDIR=~/track_passwd

cd $TPDIR

if diff -q /etc/passwd $TPDIR/passwd
then exit                                         # they are the same
else sleep 5                                      # let passwd settle
     diff /etc/passwd $TPDIR/passwd 2>&1 |        # they are DIFFERENT
     mail -s "/etc/passwd changes $(hostname -s)" "$PWMAILS"
     cp -f /etc/passwd $TPDIR                     # copy for checkin

#    "SCCS, the source motel! Programs check in and never check out!"
#     -- Ken Thompson

     rcs -q -l passwd                            # lock the archive
     ci -q -m_ passwd                            # check in new ver
     co -q passwd                                # drop the new copy
fi > /dev/null 2>&1

这是来自上述 chfn 操作脚本的示例电子邮件


-----Original Message-----
From: root [mailto:root@myhost.com]
Sent: Thursday, July 06, 2017 2:35 PM
To: Fisher, Charles J. <Charles.Fisher@myhost.com>;
Subject: /etc/passwd changes myhost

57c57
< fishecj:x:123:456:Fisher, Charles J.:/home/fishecj:/bin/bash
---
> fishecj:x:123:456:Fisher, Charles J.:/home/fishecj:/bin/csh

/etc/passwd 的第三列的进一步处理可能会检测到 UID 零（root 用户）或其他重要用户类以进行紧急操作。这可能包括将文件从 RCS 回滚到 /etc 和/或向安全联系人发送 SMS 消息。