网络文件系统的掉线监控(inotifywait)

问题背景：

在工作中遇到有批量的网络文件系统(100个左右)挂载在同一个机器上，结果一个频发的问题是：
时不时总有少量网络文件系统不明起因的掉线，时间也不确定，当然找到根本起因并处理才是王道，然而总是有些情况无法确定根本起因，而就算确定了也不肯定就100%能处理, 比方网络问题，谁能保证100%的网络可靠性呢。 所以处理这个 掉线的问题就被提上了日程.

监控方式：

要处理问题，首先要发现问题，所以首先就是要有监控，第三方工具当然很多，这里详情用系统自带的inotifywait来进行监控. 大致的思路如下：
inotifywait 可以从指定的配置文件中，读取文件/文件夹的路径，而后监控文件/文件夹 所属文件系统的unmount 事件，而后可以把 事件记录到指定文件中， 看起来应该不错。然而面临如下的问题:
A.
默认情况下inotifywait 监控到对应的umount事件之后会退出， 由于我们要批量的监控，所以当然不能由于一个挂载点的umount就退出 inotifywait, 所以需要在umount触发后继续监控. 这个通过inotify的参数 -m 即可以处理.
B.
被监控的”unmount“事件，只会被触发一次，就算持续监控，那么也只会触发一次，比方有一个cifs 共享挂载在 /mnt/win_logs , 那么当第一次发生了unmount的时候，会被inotifywait 监控到，后面自动恢复了 mount或者者手动重新进行了mount, 在重新mount之后，假如又发生了unmount, 这时候就不会触发 inotifywait的 记录了。
这样的话，只监控第一次很显著不符合我们的要求啊.我们需要一个持续的监控啊.
鄙人的处理思路如下：
要想让 inotifywait 可以持续的监控unmount, 那么最好就是 发生了unmount之后，触发 对应的mount事件，这时候inotifywait将会自动退出，确保成功mount之后. 而后再次启动inotifywait 进行监控。这个思路看起来没有什么问题，但是在实际中一旦有多个挂载点同时出发了unmount事件，那么只有第一个unmount事件会触发相应挂载点的mount，而其余的挂载点则由于inotify已经退出，所以无法实现mount，因而再次启动的inotifywait事件就无法监控到正确状态挂载状态. 所以这个方法就被排除了.

既然在持续monitoring 的情况下, 可以正确监控到第一次发生unmount的情形，所以可以考虑在发生了unmount的情况后，把inotifywait强制停掉，而后把unmount的状况处理掉, 也就是重新mount好，最后再次启动inotiywait. 由于inotifywait是并发工作的，所以假如同时发生了unmount, 那么都会记录到 对应的结果文件中的，所以需要监控 结果文件的变化。

大致的流程如下：

1. 获取inotifywait结果文件的修改日期， 记录为 m1
2. 启动inotifywait进行监控，并获取其进程pid,记录为p1（假如以 -d 方式启动，那么路径都必需用绝对路径）
3. sleep 一段时间(比方10s)，获取 结果文件的修改时间, 记录为m2
4. 比较m1,m2, 假如两者不等，那么表示等待时间内发生了 unmount. 同时用fuser来判断能否inotifywait仍然占用着 结果文件，假如仍然占用着结果文件，那么表示文件还没有写完，需要等待. 假如m1,m2两者相等，那么就回到步骤3继续进行等待，由于没有发生unmount,所以什么操作都不需要.
5. 在inotifywait 已经释放了对结果文件的占用，并且结果文件有了升级(m1和m2不等)，那么此时可以强制终止p1. 并且进行Mount操作。 mount 成功完成后，清空结果文件. 至此，一个循环完成.
6. 重复步骤1到5.

BUG:

在终止当前的inotifywait，mount 丢失的挂载点，到再次成功启动inotifywait，这个时间段假如发生了unmount，那么是记录不到的

本文原创，转载请注明出处!