Unavailable Event Occurrences

Edit online

For some event producers, there may be event occurrences that cause the monitored event to become invalid.

Some examples are:

  • The death of a process for processMon and pidProcessMon .
  • The unmounting of a file system containing monitored files for modDir and modFile .
  • The unmounting of a file system which is being monitored by utilFs .
  • The removal or renaming of a file which is being monitored by modDir or modFile
  • The removal of an event producer which is currently being used to monitor events (The RC_FROM_EVPROD will be ENODEV in this case).

Once an unavailable event occurrence has been triggered, the consumers may not continue to monitor for that event until it becomes valid again. Examples of events becoming valid again:

  • The remounting of a monitored file system.
  • The recreation of a monitored file that was deleted.
  • The recreation of a process that was being monitored.

When a local unavailable event is triggered, the AIX® Event Infrastructure kernel extension will remove the monitor file(s) affected. When a monitor file is deleted, consumers who still have the file open will be able to read their event data, but will not be able to write or block waiting for an event occurrence on that monitor file. When an unavailable event occurrence is encountered by the consumer, they should take the appropriate action (which will presumably cause the event to become valid again), close the file descriptor for the monitor file, and re-open the monitor file with the O_CREAT flag.

Local unavailable event occurrences will also cause select() and read() to unblock before the requested number of events occurrences have been triggered if the consumer has specified a NOTIFY_CNT > 1. For example, if a consumer is monitoring file /foo with a NOTIFY_CNT=3, the consumer will return from select() or read() if /foo is removed even if it is the first occurrence of an event with /foo.