Fix file descriptor leak in the postoffice plugin

[ip1981]

Closes #1838.

Signed-off-by: Igor Pashev pashev.igor@gmail.com

---

This change is 

[ip1981]

But still, this line is not hit

integrated-manager-for-lustre/iml-agent/src/daemon_plugins/postoffice.rs

Line 166 in f17ff3f

tracing::debug!("Ending Inotify Listen for {}", &conf_file);

[mkpankov]

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @ip1981)

---

iml-agent/src/daemon_plugins/postoffice.rs, line 183 at r1 (raw file):

Previously, ip1981 (Igor Pashev) wrote…

When all file descriptors referring to an inotify instance have been closed, the underlying object and its resources are freed for reuse by the kernel; all associated watches are automatically freed. --- https://linux.die.net/man/7/inotify

I'd expect inotify to close everything on drop, do you know why this is not the case?

[ip1981]

I'd expect inotify to close everything on drop, do you know why this is not the case?

I would postulate it is not dropped :)

[nlinker]

Since the issue is tricky, why not to add a description, how it is guaranteed now that the descriptors are freed?

[jgrund]

Something doesn't make sense.

In:

https://github.com/jgrund/inotify/blob/b743b410afe91a9c161c9927bbac6ddd846a0253/src/fd_guard.rs#L50-L56

the same ffi::close fn is called iff close_on_drop is true.

So, this means either one of three things:

1. Inotify is not being dropped because something else has a reference to it (have you tried using a valve on the listener stream?).
2. close_on_drop is somehow false
3. The ffi::close in drop is somehow behaving differently than the close method (unlikely).

We should figure this out instead of calling close explicitly as we're likely to use this crate elsewhere and may hit the same issue again.