Rich Megginson (richmegginson) wrote,
Rich Megginson

Monitoring epoll events

When doing analysis of daemon processes that use epoll, you may want to take a peek inside the epoll structure. This is available via the /proc/$PID/fdinfo.

  1. Find the process id (PID) of the daemon process e.g. # pidof procname

  2. Find the epoll file descriptor (fd) e.g. # epollfd=`ls -al /proc/$PID/fd | awk '/eventpoll/ {print $9}'`

  3. Dump the information about the epoll fd e.g. # cat /proc/$PID/fdinfo/$epollfd

The information looks like this:
pos:    0
flags:  02000002
tfd:        6 events:       19 data:                6
tfd:       20 events:       19 data:               14
tfd:       21 events:       19 data:               15
tfd:     2446 events:       19 data:              98e
tfd:     1991 events:       19 data:              7c7
tfd:     1065 events:       19 data:              429
tfd:     2444 events:       19 data:              98c

Each tfd is the decimal number of the file descriptor being polled by epoll. The events field is the hex value of the flags specified in the field when calling epoll_ctl. 0x19 is EPOLLIN|EPOLLERR|EPOLLHUP. The data field is the hex value of the tfd decimal value.

If you suspect that your application is leaking file descriptors, and you believe the problem is that the application is adding fds to epoll but never deleting them, you can periodically poll the epoll fdinfo, to look for descriptors that are persistent. You should first figure out which file descriptors your application uses as persistent descriptors e.g. the listener sockets or the eventfd notifier.
Tags: 389, epoll
  • Post a new comment


    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.