Control: reassign 795934 icedove Control: retitle 795934 leaks file descriptors to attachment handlers Control: found 795934 38.1.0-1
On 18/08/15 08:12, Andrew King wrote: > After opening pdf attachments from my mail client (icedove), each > evince process keeps an open network connection to the mail server (long > after the document has completed loading). > > (I'm assuming that evince is retrieving the document, otherwise I am > unsure why it needs a network connection in the first place). evince does not retrieve the document itself; icedove does give it a filename in /tmp for the attachment. The problem is that evince is executed as a subprocess of icedove, and icedove does not either mark its open file descriptors as close-on-exec, or close all file descriptors (except for stdin, stdout, stderr and any other deliberately-inherited fds) in the child process after fork() but before exec(). Any process that executes subprocesses should do at least one of those two things, preferably both. As a result, file descriptors that were open in icedove (including sockets, pipes, the cache, and mailbox files) remain open in the child process. I can reproduce this with a different attachment handler, which demonstrates that this is not unique to evince: if I open an attachment with gvim, then "ls -l /proc/$(pgrep gvim)/fd", I can see that gvim has incorrectly inherited various open file descriptors pointing to sockets, pipes, ~/.icedove/*/Cache/*, and ~/.icedove/*/ImapMail/*/*.msf. Quoting the rest of Andrew's report for the icedove maintainer. > The problem is that after I have 10 documents open my mail client is > unable to contact (or authenticate to) the mail server as it limits the > number of active connections to 10 per IP. > > Evince should close the connection once the document is loaded, or > better yet, load the document from /tmp and not make/keep any network > connections. > > The immediate workaround is to save all attachments and then open > them (which is somewhat inconvenient). Regards, S