Closing of all FD's breaks existing logging and connections

[thijsc]

I'm debugging a problem some customers of ours are running into. Our monitoring gem has some file descriptors open, but these are closed after a daemonize call:

3.upto(8192) do |i|
  IO.for_fd(i).close rescue nil
end

This happens in

daemons/lib/daemons/daemonize.rb

Line 132 in 73ffe58

3.upto(8192) do |i|

From my point of view it is actually essential that these FD's stay open after the daemonize. Could you explain why this behaviour is present here? Would you be open to removing it?

[sodabrew]

Can you initialize the monitoring calls after daemonizing?

It is unusual and generally strongly-not-desired for a daemon to inherit and use open file descriptors from its parent. If you do want this scenario, you should not daemonize and remain a child process.

[thijsc]

We can't be sure that the monitoring gets initialized after the daemonize call unfortunately.

One use case where this is causing issues if when our gem gets initialized from Rails which starts before DJ daemonizes. The only way I can see at the moment to fix this is to make our gem able to properly detect these failures and re-open everything it needs. That's possible, but quite a big change just to support this edge case. So I'm just making sure it's really necessary to do this.

Not sure why these close calls are necessary though. A standard Unix daemon call does not close all FD's to my knowledge. See http://man7.org/linux/man-pages/man3/daemon.3.html. Were there any specific scenario's or issues that made it necessary to add this behaviour?

[thuehlinger]

I must admit I don't remember any specific scenarios that required closing all FDs. If I remember corretly, this code was already in daemonize.rb by Travis Whitton which forms the basis for daemons. Not knowing whether people are actually relying on the fact that all FDs are closed, I would however not like to remove this part. Would a switch help?

[sodabrew]

It's been standard practice to close excess file descriptors for about two decades - it was once common for shells to leak file descriptors to processes executed on the command line. I don't know if this is still true; it may be cargo-cult at this point, or it may be quietly critical.

If at all possible for your application to work around the situation, I would highly recommend that. I see the issue there with launching a delayed job from a rails command line, I'm not sure what to advise :/

[thijsc]

I did some further digging and have been able to work around this. For future reference, Delayed Job has a pretty neat workaround. They store all FD's and reopen them:

https://github.com/collectiveidea/delayed_job/blob/401f43e076c25559ec65fdfa611a0d94b7b29eb1/lib/delayed/worker.rb#L78