背景:工作中有大量的网络文件系统(大约100个)挂载在同一台机器上。这样一来，一个经常出现的问题就是:不时有少量网络文件系统因为未知原因断开连接，时间不确定。当然，找到根源，处理好才是王道。但总有一些情况是无法确定根本原因的，即使确定了，也不一定能百分百处理好。比如网络问题，谁能百分百保证？ 因此，处理这种辍学问题已被提上日程。监控法:处理问题首先要发现问题，所以首要的是监控。当然还有很多第三方工具。在这里，细节由系统自带的inotifywait监控。大致思路如下:inotifywait可以从指定的配置文件中读取文件/文件夹的路径，然后监听文件/文件夹所属的文件系统的卸载事件，再将事件记录到指定的文件中。 但面临以下问题:a .默认情况下，inotifywait会在监测到相应的umount事件后退出。因为我们要批量监控，当然不能因为卸载一个挂载点就退出inotifywait。因此，有必要在触发卸载后继续监控。inotify的这个参数-m可以处理。b .受监控的“卸载”事件将仅触发一次。即使连续监测，也只会触发一次。例如，如果cifs共享装载在/mnt/win_logs上，则当第一次卸载时，将由inotifywait监视，然后装载将自动恢复或手动重新装载。重新挂载后，如果再次发生卸载，此时不会触发inotifywait的记录。 在这种情况下，只监测第一次显然是达不到我们的要求的。我们需要持续的监控。我的思路是这样的:如果inotifywait可以持续监控unmount，最好在unmount之后触发相应的mount事件。此时，inotifywait将自动退出以确保成功挂载，然后再次启动inotifywait进行监控。 这种想法看似没有问题，但实际操作中，一旦多个挂载点同时启动了unmount事件，只有第一个unmount事件会触发对应挂载点的挂载，而其余挂载点都无法挂载，因为inotify已经退出。因此，再次启动的inotifywait事件无法监控mount的正确状态。所以排除这种方法。由于在持续监控的情况下可以正确监控到第一次卸载，所以可以认为卸载发生后，会强制停止inotifywait，然后再处置卸载情况。也就是重新挂载好，最后重新开始inotiywait。由于inotifywait是并发工作的，如果同时发生了unmount，就会被记录在相应的结果文件中，所以需要监控结果文件的变化。 一般过程如下:获取inotifywait结果文件的修改日期，记为m1，启动inotifywait进行监控，并获取其进程pid，记为p1(如果是在-d模式下启动，那么所有路径必须使用绝对路径)，休眠一段时间(比如10s)，获取结果文件的修改时间，记为m2，比较M1和M2，如果不相等，那么说明在等待时间内发生了卸载。同时使用fuser来判断inotifywait是否仍然占用结果文件。如果仍然占用结果文件，说明文件还没有完成，需要等待。如果M1和M2相等，那么回到步骤3，继续等待。由于没有发生卸载，因此不需要任何操作。如果在inotifywait中已经释放了对结果文件的占用，并且已经升级了结果文件(m1和m2不同)，那么可以强制终止p1，进行挂载操作。 成功完成装载后，清空结果文件。至此，一个循环完成。重复步骤1至5。BUG:当前inotifywait终止后，mount丢失的挂载点会再次成功启动。如果卸载发生在这个时期，那么不能记录的就是这篇文章的原文。转载请注明出处！