Linux inotify install and create a device

Source: Internet
Author: User
Tags andrew morton inotify

Do you want to know the truth about the Linux inotify system? Do you want to know what is inherent in the Linux inotify system, I will only give you a full introduction to Linux inotify using Linux inotify to monitor Linux File System events.

Linux inotify is a file system event monitoring mechanism and is planned to be included in the forthcoming Linux kernel as an effective replacement for dnotify. Dnotify is a file monitoring mechanism supported by earlier kernels. Linux inotify is a powerful, fine-grained, asynchronous mechanism that meets various file monitoring needs and is not limited to security and performance.

Next, let's learn how to install Linux inotify and how to build an example user space application to respond to file system events. File System event monitoring is necessary for various programs from the File Manager to the security tool, but there are some limitations in the early kernel standards of dnotify, this makes us look forward to a more comprehensive mechanism. With this expectation, we found Linux inotify, a more modern alternative to file system event monitoring.

Why Linux inotify?

There are many reasons for replacing dnotify with Linux inotify. The first reason is that dnotify requires you to open a file descriptor for each directory to be monitored for change. When multiple directories are monitored at the same time, this consumes a lot of resources because it may limit the file descriptor of each process.

In addition, the file descriptor locks the Directory and does not allow unmount.) The supported devices may cause problems in the environment where removable media exists. When Linux inotify is used, if you are monitoring files on the uninstalled file system, the monitoring will be automatically removed and you will receive an unload event.

The second reason why dnotify is not as complex as Linux inotify is that dnotify is a bit complicated. Note that the monitoring granularity of a simple File System Using the dnotify infrastructure is only at the directory level. To use dnotify for more fine-grained monitoring, application programmers must keep a stat structure cache for each monitored directory.

The stat structure cache of the user space needs to be used to determine what changes have occurred to the directory when the notification signal is received. When a notification signal is obtained, the stat structure list is generated and compared with the latest status. Obviously, this technology is not ideal.

Another advantage of Linux inotify is that it uses file descriptors as the basic interface, allowing application developers to use select and poll to monitor devices. This allows effective multi-channel I/O and integration with the mainloop of Glib. On the contrary, the signals used by dnotify often make programmers feel a headache and not very elegant.

Linux inotify solves these problems by providing a more elegant API that uses the least file descriptor and ensures more fine-grained monitoring. Communication with Linux inotify is provided by the device node. For the above reasons, Linux inotify is your best choice for monitoring files on Linux 2.6.

Install Linux inotify

The first step to install Linux inotify is to determine whether your Linux kernel supports it. The easiest way to check the release is to find whether the/dev/Linux inotify device exists. If this device exists, you can jump to the Linux inotify section in a simple application.

At the time of writing this article, Linux inotify was included in the Linux 2.6-mm directory tree of Andrew Morton, and some Linux distributions are providing kernels that support Linux inotify, including Gentoo and Ubuntu) or supplement the kernel packages such as Fedora and SuSE ).

Because Andrew may remove Linux inotify support from the directory tree as needed, and the Linux inotify version is still in frequent development stages, we strongly recommend that you install patches from the beginning. If the device is missing, you may need to patch the kernel and create the device.

Linux inotify patches can be obtained from Linux Kernel Archives by patching the Kernel. For more information, see the link in the references section ). You should apply the patch with the highest version number for a specific kernel. Each release version processes different kernel installation, but the following describes a general guide. Note: Obtain the source file of the 2.6 Linux Kernel from the Linux Kernel Archives release. If applicable, obtain the latest stable version.

Start from entering the kernel source file directory: bash :~ $ Cd/usr/src because you installed the kernel source file earlier, you need to decompress it: bash :~ $ Sudo tar jxvf linux-source-2.6.8.1.tar.bz2 now directs your symlink to the new source file directory tree: bash :~ $ Sudo ln-sf linux-source-2.6.8.1 linux change the current directory to the kernel source file directory just created:

Bash :~ $ Cd linux copy Linux inotify Patch: bash :~ $ Sudo cp ~ /Linux inotify */usr/src patch the kernel: bash :~ $ Sudo patch-p1 <../Linux inotify *. patch build kernel: bash :~ $ Sudo make menuconfig

Configure your kernel as usual to ensure that Linux inotify works properly. If necessary, add the new kernel to the boot loader, but remember to maintain the image and boot loader options of the old kernel. This step varies with different boot loaders. For more information about specific boot loaders, see references ).

Reboot the computer and choose to enable the new kernel of Linux inotify. Before proceeding, test your new kernel to make sure it works properly.

Create a Linux inotify Device

Next, make sure to create the/dev/Linux inotify device. Follow these steps to complete the process. Important: The device number may change, so pay attention to it to make sure it is updated at any time! If Linux installation supports the udev function, it automatically keeps updated.

After you reboot to the new kernel, you must obtain the device number: bash :~ $ Dmesg | grep ^ example of the result returned by Linux inotify: Linux inotify device minor = 63 because Linux inotify is a misc device, the primary device number is 10. To create a device node as the root user, run the following command: bash :~ $ Mknod/dev/Linux inotify c 10 63

NOTE: If necessary, replace "63" with the appropriate device number ". You can set the permissions you want at will. An example of permission settings is as follows: bash :~ $ Chown root: root/dev/Linux inotify bash :~ $ Chmod 666/dev/Linux inotify is now ready to use the Linux inotify device for file system monitoring. Back to Top

Linux inotify is used in simple applications to demonstrate how to use Linux inotify. I will show how to construct a sample program that monitors arbitrary directories or individual files for file system events. I will show at a high level how easy Linux inotify makes file system monitoring.

The simple example of the Main method shows how easy it is to set monitoring in any directory of Linux inotify. We will see the main helper routine later. You can obtain the sample code used in these examples in the download section of this article.

List 1. Set monitoring on the directory

 
 
  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. }  


Important helper Methods

The following is the most important helper routine for each Linux inotify-based application: to open the Linux inotify device for reading. Queues events read from this device. The actual processor per event that allows applications to effectively process event notifications.

I will not delve into the details of event queuing, because we can use some policies to avoid queuing. The provided code shows this method. More advanced multi-threaded methods can be implemented elsewhere. In those implementations, the reader thread simply executes select () on the Linux inotify device (), then, copy the event to some storage space shared by the thread or something like the asynchronous message queue of Glib. In the future, the processor thread will process the event here.

Listing 2. Enable the Linux inotify Device

 
 
  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. }  

This should be familiar to anyone who has programmed files on Linux.

Listing 3. Actual event processing routine

 
 
  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. }  

In each case statement, you can execute any methods that have been implemented and meet your needs. As for performance monitoring, you can determine which files are most frequently read and their opening duration. This kind of monitoring is very convenient, because in some cases, if the file is repeatedly read by the application within a short period of time, it will cache the file in the memory instead of returning the disk for reading, to improve performance.

It is easy to give examples of event-specific processors that execute interesting operations. For example, if you are implementing a metadata storage index for the underlying file system, you may find a file creation event and trigger a metadata mining operation on the file soon. In a secure environment, if a file is written to a directory that nobody can write, you will trigger some forms of system alarms.

Note that Linux inotify supports many very fine-grained events, such as CLOSE and CLOSE_WRITE. The code in this article lists many events that you may not want to see every time you run the code. In fact, as long as possible, you can and should only request a subset of events that are useful to your application.

For testing purposes, the Code provided in this article is executed by strictly using the full mask, for example, the sample code that can be downloaded [see references] near line 51st of the main method or line 29th in Listing 1 above.) shows many events. Application programmers usually want to have more options, and you need a more specific mask to meet your needs. This allows you to delete uninterested entries from the catch statement in the handle_event () method.

  1. Linux locale manually mounts the kernel
  2. Detailed discussion on Linux User Creation commands
  3. Linux Makefile
  4. In-depth discussion on Linux partition Solutions
  5. Knowledge about Linux SNMP and RRD database updates

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.