Nikos Mavrogiannopoulos schreef op 2014-09-19 17:14: > On Fri, Sep 19, 2014 at 5:07 PM, Nikos Mavrogiannopoulos > <n.mavrogiannopoulos at gmail.com> wrote: >>>> Are these discussions public? Does that change solve the issue? Is >>>> the >>>> loop on dnsmasq on tun or udp socket? >>> The problem has not re-occured since, but I won't be able to say >>> with confidence until some more >>> time has passed. >> If that solves the issue, we'd better wrap all close calls in >> ocserv's >> main thread. > > Having read: > http://lwn.net/Articles/576478/ > https://lkml.org/lkml/2002/7/17/165 > > it gets more confusing. As I understand close shouldn't have been > interrupted in linux. Interesting. I'm totally in favor of close(2) having a policy of never failing except for EBADF, but that's not what the man page says (Ubuntu 14.04.1). However, the close(2) wrapper was not the main goal of the patch. I was looking for a potential reason why tun devices weren't properly closed and came across the handle_script_exit function that contains the comment: /* we close the lease tun fd both on success and failure. * The parent doesn't need to keep the tunfd, and if it does, * it causes issues to client. */ And then proceeds to close the tun fd only if proc->tun_lease.name doesn't contain an empty string. The patch removes that condition. I added the close(2) wrapper as an extra measure, but I now realize that's unnecessary (on Linux at least). I should note that I'm not familiar with the code at all. There might be a good reason why that condition is in place. I just found it suspicious and worth a shot to remove it in order to debug the problem. -- Thomas Veerman