Socket creation leaks file descriptors

[ollipa]

Version of neli
0.7.0-rc2

Does the documentation specify that neil's behavior is correct?
No.

Does there appear to be a mistake in the netlink documentation based on the kernel code?
No.

Describe the bug
Creating new sockets seems to slowly leak file descriptors.

To Reproduce
Steps to reproduce the behavior:

loop {
    let socket = NlRouter::connect(NlFamily::Generic, None, Groups::empty());
}

Expected behavior
I would expect dropping NlRouter to clean up and close file descriptors.

Additional context
Long running process that creates new NlRouter instances stop working after open file limit is reached.

lsof -p 765069 2> /dev/null
COMMAND PID    USER   FD      TYPE  DEVICE SIZE/OFF     NODE NAME
netlink 765069 user  cwd       DIR  253,1     4096  17732909 /home/user/netlink
netlink 765069 user  rtd       DIR  253,1     4096         2 /
netlink 765069 user  txt       REG  253,1 27632920  20945955 /home/user/netlink/target/debug/netlink
netlink 765069 user  mem       REG  253,1  2216304  31727755 /usr/lib/x86_64-linux-gnu/libc.so.6
netlink 765069 user  mem       REG  253,1   940560  31727758 /usr/lib/x86_64-linux-gnu/libm.so.6
netlink 765069 user  mem       REG  253,1   125488  31722342 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
netlink 765069 user  mem       REG  253,1   240936  31727752 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
netlink 765069 user    0u      CHR  136,2      0t0         5 /dev/pts/2
netlink 765069 user    1u      CHR  136,2      0t0         5 /dev/pts/2
netlink 765069 user    2u      CHR  136,2      0t0         5 /dev/pts/2
netlink 765069 user    3u  a_inode   0,14        0        55 [eventpoll]
netlink 765069 user    4u  a_inode   0,14        0        55 [eventfd] 
netlink 765069 user    5u  a_inode   0,14        0        55 [eventpoll]
netlink 765069 user    6u  netlink             0t0 101896854 GENERIC
netlink 765069 user    7u  netlink             0t0 101900301 GENERIC
netlink 765069 user    8u  netlink             0t0 101898862 GENERIC
...clip...
netlink 765069 user 1021u  netlink             0t0 103272955 GENERIC
netlink 765069 user 1022u  netlink             0t0 103298799 GENERIC
netlink 765069 user 1023u  netlink             0t0 103280090 GENERIC

[jbaublitz]

Hi @ollipa! I think there are two things at play here.

One piece is that you're using the library in a way that was not intended. There really should only need to be at most one NlRouter per protocol that you're using in netlink. They are intentionally designed to handle all messages for a given protocol, multicast included. I think you're missing out on some of the benefit if you're creating an NlRouter for each request.

That being said, there is also a bug here. Dropping an NlRouter should clean up the message processing thread which it does not currently do. Because the NlSocket is wrapped in an Arc which has one reference owned by the processing thread, the socket is never dropped.

I can fix the bug on my end, but I'd strongly recommend designing your usage of NlRouter to keep them alive for as long as possible. I don't anticipate that you will get good performance if you spin them up and shut them down a lot.

[jbaublitz]

I'm working on the fix now. Hope to get it working in a couple of days.