Linux inotify使用安装创建设备

运维 系统运维
Linux inotify 是文件系统事件监控机制,计划包含在即将发布的 Linux 内核中作为 dnotify 的有效替代。dnotify 是较早内核支持的文件监控机制。Linux inotify一种强大的、细粒度的、异步的机制,它满足各种各样的文件监控需要,不仅限于安全和性能。

想知道到Linux inotify系统的真相么,想知道Linux inotify系统中藏有的内在奥义么,只有我来给大家全面讲解介绍Linux inotify系统使用 Linux inotify 监控 Linux 文件系统事件.
 
Linux inotify 是文件系统事件监控机制,计划包含在即将发布的 Linux 内核中作为 dnotify 的有效替代。dnotify 是较早内核支持的文件监控机制。Linux inotify一种强大的、细粒度的、异步的机制,它满足各种各样的文件监控需要,不仅限于安全和性能。

下面让我们一起学习如何安装 Linux inotify 和如何构建一个示例用户空间应用程序来响应文件系统事件。文件系统事件监控对于从文件管理器到安全工具的各种程序都是必要的,但是 dnotify(早期内核中的标准)存在一些局限性,这使我们期待出现一种更加完善的机制。抱着这种期待,我们发现了 Linux inotify,一种更加现代化的文件系统事件监控替代品。

为什么使用 Linux inotify?

使用 Linux inotify 取代 dnotify 的原因有很多。***个原因是,dnotify 需要您为每个打算监控是否发生改变的目录打开一个文件描述符。当同时监控多个目录时,这会消耗大量的资源,因为有可能达到每个进程的文件描述符限制。

除此之外,文件描述符会锁定目录,不允许卸载(unmount)支持的设备,这在存在可移动介质的环境中会引发问题。在使用 Linux inotify 时,如果正在监控被卸载的文件系统上的文件,那么监控会被自动移除并且您会接收到一个卸载事件。

dnotify 不如 Linux inotify 的第二个原因是 dnotify 有点复杂。注意,使用 dnotify 基础设施的简单文件系统监控粒度只停留于目录级别。为了使用 dnotify 进行更细粒度的监控,应用程序编程人员必须为每个受监控的目录保留一个 stat 结构的缓存。

该用户空间的 stat 结构缓存需要用来明确确定当接收到通知信号时目录发生了什么变化。当获得通知信号时,生成 stat 结构列表并与***的状态相比较。显而易见,这种技术是不理想的。

Linux inotify 的另一个优点是它使用文件描述符作为基本接口,使应用程序开发者使用 select 和 poll 来监控设备。这允许有效的多路 I/O 和与 Glib 的 mainloop 的集成。相反,dnotify 所使用的信号常常使程序员头疼并且感觉不太优雅。

Linux inotify 通过提供一个更优雅的 API 解决了这些问题,该 API 使用最少的文件描述符,并确保更细粒度的监控。与 Linux inotify 的通信是通过设备节点提供的。基于以上原因,对于监控 Linux 2.6 平台上的文件,Linux inotify 是您最明智的选择。

回页首安装 Linux inotify

安装 Linux inotify 的***步是确定您使用的 Linux 内核是否支持它。检查发行版的最简单方法是,寻找是否存在 /dev/Linux inotify 设备。如果存在该设备,您可以跳到 在简单应用程序中使用 Linux inotify 一节。

在撰写本文时,Linux inotify 包含在 Andrew Morton 的 Linux 2.6-mm 目录树中,而且一些 Linux 发行版正在提供支持 Linux inotify 的内核(包括 Gentoo 和 Ubuntu)或者具有提供支持的补充内核包(例如 Fedora 和 SuSE)。

因为 Andrew 可能会根据需要从目录树删除对 Linux inotify 的支持,并且 Linux inotify 版本还处于频繁的开发阶段,所以强烈建议您从头开始打补丁。 如果缺少该设备,您可能需要对内核打补丁并创建该设备。

为 Linux inotify 对内核打补丁可以从 Linux Kernel Archives 获得 Linux inotify 补丁(请参阅 参考资料 一节的链接)。 您应该为特定的内核应用***版本编号的补丁。每个发行版处理内核的安装都有所不同,但以下介绍的是一个通用指导。注意:从 Linux Kernel Archives 获取发行版 2.6 Linux 内核源文件,如果合适,请获取***的稳定版本。

从进入内核源文件目录开始: bash:~$ cd /usr/src 因为您早先安装了内核源文件,现在需要将它解压缩: bash:~$ sudo tar jxvf linux-source-2.6.8.1.tar.bz2 现在,使您的 symlink 指向新的源文件目录树: bash:~$ sudo ln -sf linux-source-2.6.8.1 linux 改变当前目录到刚才创建的内核源文件目录:

bash:~$ cd linux 拷贝 Linux inotify 补丁: bash:~$ sudo cp ~/Linux inotify* /usr/src 将内核打补丁: bash:~$ sudo patch -p1 < ../Linux inotify*.patch 构建内核: bash:~$ sudo make menuconfig

像平时一样配置您的内核,确保 Linux inotify 工作正常。如果必要,请将新内核添加到引导加载程序中,但是一定要记住维护旧内核的映像和引导加载程序选项。这一步对于不同引导加载程序有所不同(请参阅 参考资料 了解关于特定引导加载程序的更多信息)。

重新引导计算机并选择启用 Linux inotify 的新内核。在继续往下操作前,测试您的新内核以确保它工作正常。

创建 Linux inotify 设备

接下来,您需要确保创建 /dev/Linux inotify 设备。以下步骤带领您完成这个过程。重要注意:次设备编号可能会发生改变,所以您需要多加注意以确保它随时更新!如果 Linux 安装支持 udev 功能,它将会自动保持更新。

在重新引导到新内核后,您必须获取次设备编号: bash:~$ dmesg | grep ^Linux inotify 返回结果示例如下: Linux inotify device minor=63 因为 Linux inotify 是 misc 设备,所以主设备编号是 10。要创建设备节点作为根用户,请执行以下命令: bash:~$ mknod /dev/Linux inotify c 10 63

注意:如有必要,请使用合适的次设备编号替换“63”。 您可以随意设置您想要的权限。一个示例权限设置如下所示: bash:~$ chown root:root /dev/Linux inotify bash:~$ chmod 666 /dev/Linux inotify 现在准备使用 Linux inotify 设备进行文件系统监控。 回页首

在简单应用程序中使用 Linux inotify为演示 Linux inotify 的使用,我将展示如何为文件系统事件构造一个监控任意目录(或单个文件)的示例程序。我将站在一个较高的层次上来展示 Linux inotify 使文件系统监控变得多么容易。

Main 方法这个简单的示例向我们展示 Linux inotify 在任意目录上设置监控是多么容易。稍后我们将看到主要的帮助器例程。您可以在本文的 下载 一节获取这些例子中使用的示例代码。

清单 1. 在目录上设置监控

  1. /* This program will take as argument a directory name and monitor it,  
  2. printing event notifications to the console.  
  3. */  
  4. int main (int argc, char **argv)  
  5. {  
  6. /* This is the file descriptor for the Linux inotify device */  
  7. int Linux inotify_fd;  
  8. /* First we open the Linux inotify dev entry */  
  9. Linux inotify_fd = open_Linux inotify_dev();  
  10. if (Linux inotify_fd < 0)  
  11. {  
  12. return 0;  
  13. }  
  14. /* We will need a place to enqueue Linux inotify events,  
  15. this is needed because if you do not read events  
  16. fast enough, you will miss them.  
  17. */  
  18. queue_t q;  
  19. q = queue_create (128);  
  20. /* Watch the directory passed in as argument  
  21. Read on for why you might want to alter this for  
  22. more efficient Linux inotify use in your app.  
  23. */  
  24. watch_dir (Linux inotify_fd, argv[1], ALL_MASK);  
  25. process_Linux inotify_events (q, Linux inotify_fd);  
  26. /* Finish up by destroying the queue, closing the fd,  
  27. and returning a proper code  
  28. */  
  29. queue_destroy (q);  
  30. close_Linux inotify_dev (Linux inotify_fd);  
  31. return 0;  
  32. }  


重要的帮助器方法

以下是每个基于 Linux inotify 的应用程序共同的最重要的帮助器例程: 为读取而打开 Linux inotify 设备。 对从该设备读取的事件进行排队。 允许应用程序对事件通知进行有用处理的实际的每事件处理器。

我不会深入钻研事件排队的细节,因为我们能够使用一些策略来避免排队。提供的代码中就展示了一个这样的方法;更先进的多线程方法可以并且已经在其他地方实现。在那些实现中,读者线程简单地在 Linux inotify 设备上执行 select(),然后将事件拷贝到一些线程共享的存储空间(或者一些像 Glib 的异步消息队列的东西),以后处理器线程会处理这里的事件。

清单 2. 打开 Linux inotify 设备

  1. /* This simply opens the Linux inotify node in dev (read only) */  
  2. int open_Linux inotify_dev ()  
  3. {  
  4. int fd;  
  5. fd = open("/dev/Linux inotify", O_RDONLY);  
  6. if (fd < 0)  
  7. {  
  8. perror ("open(\"/dev/Linux inotify\", O_RDONLY) = ");  
  9. }  
  10. return fd;  
  11. }  

这对任何一个在 Linux 系统上进行过文件编程的人来说都应该是熟悉的。

清单 3. 实际的事件处理例程

  1. /* This method does the dirty work of determining what happened,  
  2. then allows us to act appropriately  
  3. */  
  4. void handle_event (struct Linux inotify_event *event)  
  5. {  
  6. /* If the event was associated with a filename, we will store it here */  
  7. char * cur_event_filename = NULL;  
  8. /* This is the watch descriptor the event occurred on */  
  9. int cur_event_wd = event->wd;  
  10. if (event->len)  
  11. {  
  12. cur_event_filename = event->filename;  
  13. }  
  14. printf("FILENAME=%s\n", cur_event_filename);  
  15. printf("\n");  
  16. /* Perform event dependent handler routines */  
  17. /* The mask is the magic that tells us what file operation occurred */  
  18. switch (event->mask)  
  19. {  
  20. /* File was accessed */  
  21. case IN_ACCESS:  
  22. printf("ACCESS EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  23. cur_event_filename, cur_event_wd);  
  24. break;  
  25. /* File was modified */  
  26. case IN_MODIFY:  
  27. printf("MODIFY EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  28. cur_event_filename, cur_event_wd);  
  29. break;  
  30. /* File changed attributes */  
  31. case IN_ATTRIB:  
  32. printf("ATTRIB EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  33. cur_event_filename, cur_event_wd);  
  34. break;  
  35. /* File was closed */  
  36. case IN_CLOSE:  
  37. printf("CLOSE EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  38. cur_event_filename, cur_event_wd);  
  39. break;  
  40. /* File was opened */  
  41. case IN_OPEN:  
  42. printf("OPEN EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  43. cur_event_filename, cur_event_wd);  
  44. break;  
  45. /* File was moved from X */  
  46. case IN_MOVED_FROM:  
  47. printf("MOVE_FROM EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  48. cur_event_filename, cur_event_wd);  
  49. break;  
  50. /* File was moved to X */  
  51. case IN_MOVED_TO:  
  52. printf("MOVE_TO EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  53. cur_event_filename, cur_event_wd);  
  54. break;  
  55. /* Subdir was deleted */  
  56. case IN_DELETE_SUBDIR:  
  57. printf("DELETE_SUBDIR EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  58. cur_event_filename, cur_event_wd);  
  59. break;  
  60. /* File was deleted */  
  61. case IN_DELETE_FILE:  
  62. printf("DELETE_FILE EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  63. cur_event_filename, cur_event_wd);  
  64. break;  
  65. /* Subdir was created */  
  66. case IN_CREATE_SUBDIR:  
  67. printf("CREATE_SUBDIR EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  68. cur_event_filename, cur_event_wd);  
  69. break;  
  70. /* File was created */  
  71. case IN_CREATE_FILE:  
  72. printf("CREATE_FILE EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  73. cur_event_filename, cur_event_wd);  
  74. break;  
  75. /* Watched entry was deleted */  
  76. case IN_DELETE_SELF:  
  77. printf("DELETE_SELF EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  78. cur_event_filename, cur_event_wd);  
  79. break;  
  80. /* Backing FS was unmounted */  
  81. case IN_UNMOUNT:  
  82. printf("UNMOUNT EVENT OCCURRED: File \"%s\" on WD #%i\n",  
  83. cur_event_filename, cur_event_wd);  
  84. break;  
  85. /* Too many FS events were received without reading them  
  86. some event notifications were potentially lost.  */  
  87. case IN_Q_OVERFLOW:  
  88. printf("Warning: AN OVERFLOW EVENT OCCURRED: \n");  
  89. break;  
  90. case IN_IGNORED:  
  91. printf("IGNORED EVENT OCCURRED: \n");  
  92. break;  
  93. /* Some unknown message received */  
  94. default:  
  95. printf ("UNKNOWN EVENT OCCURRED for file \"%s\" on WD #%i\n",  
  96. cur_event_filename, cur_event_wd);  
  97. break;  
  98. }  
  99. }  

在每一条 case 语句中,您可以随意执行任意已实现并且满足需要的方法。 至于性能监控,您可以确定哪些文件是最经常被读取的和它们打开的持续时间。这种监控非常方便,因为在某些情况下,如果文件在短时间内被应用程序重复地读取,它会将文件缓存在内存中而不用返回磁盘去读取,从而提高性能。

很容易举出一些执行有趣操作的特定于事件的处理器的例子。比如,如果您是在为底层文件系统实现一个元数据存储索引,您可能会寻找文件创建事件,不久还会在该文件上触发一个元数据挖掘操作。在安全环境中,如果文件被写入一个无人可以写入的目录,您会触发某些形式的系统警报。

请注意,Linux inotify 支持许多非常细粒度的事件 —— 例如 CLOSE 与 CLOSE_WRITE。 本文中的代码所列举的许多事件,可能您并不希望在每次代码运行时都看到。实际上,只要可能,您可以并且应该只请求对您的应用程序有用的事件子集。

出于测试目的,本文章提供的代码通过严格使用完整掩码(如可下载的示例代码[请参阅 参考资料] 中 main 方法的第 51 行附近或者上面的 清单 1 中的第 29 行所执行的)展示了许多事件。应用程序员通常想要有更多选择,而您则需要更特定的掩码来满足您的需要。这使您可以从上述的 handle_event() 方法中的 catch 语句删除不感兴趣的条目。

【编辑推荐】

  1. Linux locale手工挂载内核内核
  2. 有关Linux创建用户命令的详细讨论
  3. Linux Makefile介绍自动编译和链接
  4. Linux分区方案深度讨论
  5. Linux SNMP相关知识与RRD数据库更新
责任编辑:佚名 来源: csdn
相关推荐

2021-10-15 10:05:04

物联网安全设备

2010-11-04 10:16:11

inotify监控Linux文件系统

2017-10-11 14:45:58

Linuxinotify功能实现原理

2010-02-25 17:36:38

Linux USB

2020-10-10 19:30:25

lshwLinux设备信息

2009-10-28 12:05:32

linux监控技术

2014-05-12 16:40:13

Linux命令快照

2009-09-11 08:36:16

linux块字符设备linux操作系统

2010-05-07 15:40:18

ibmdwLinux

2010-05-10 15:14:13

inotifyLinux文件系统

2010-02-03 13:58:42

Linux Trac

2010-02-07 14:57:37

Ubuntu samb

2018-11-26 08:45:29

Linux驱动程序命令

2020-05-09 12:01:40

Linux开源软件SDN

2012-09-12 09:10:23

Android虚拟设备创建指南

2009-06-26 17:33:30

Wiresharkpcaplinux

2010-02-03 15:54:58

Linux SVN安装

2009-12-16 15:59:13

Linux设备文件管理

2022-09-28 12:57:13

USBLinux系统

2020-09-22 07:29:14

Linux stat
点赞
收藏

51CTO技术栈公众号