Re: [autofs] automount does not close file descriptors at start
On Mon, 21 Feb 2005 [EMAIL PROTECTED] wrote: On Mon, 21 Feb 2005 12:57:22 +0800, Ian Kent said: This is the first time I've heard this and the first time I wrote a Unix daemon was fifteen years ago. As far as I'm concerned redirecting stdin, stdout and stderr to the null device, then closing it and setting the process to a be the group leader (as autofs does) should be all that's needed to daemonize a process. So are we saying that we don't trust the kernel to reliably duplicate the state of file handles when we fork? No, you have it 180 degrees off. ;) Perhaps the sentence above should start "So you are saying that ...". I'm arguing that I should'nt have to perform a loop closing file descriptors I haven't opened. We *do* trust the kernel to reliably duplicate the state of file handles. This confirms above. So if we're about to do the whole double-fork thing and all that, we want to loop around and close all the file descriptors we don't want leaking to the double-forked daemon. Yes, we do something reasonable with fd 0,1,2 - but we probably also want to do something with that unclosed fd 3 that's still open on /etc/mydaemon.cf, and any other file descriptors we've left dangling in the breeze after initialization. Now this is a good point. I don`t do a double fork in autofs (inherited code), although, long ago I did. Do we really need to do a double fork to disassociate from the controlling terminal or is a single fork and close etc. enough? I notice that "setsid()" should do this but I've not seen it bofore. Is that sufficient to do the job instead of the double fork? And it looks like the automount process I just started still has a tty, grumble Ian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [autofs] automount does not close file descriptors at start
On Mon, 21 Feb 2005 [EMAIL PROTECTED] wrote: On Mon, 21 Feb 2005 12:57:22 +0800, Ian Kent said: This is the first time I've heard this and the first time I wrote a Unix daemon was fifteen years ago. As far as I'm concerned redirecting stdin, stdout and stderr to the null device, then closing it and setting the process to a be the group leader (as autofs does) should be all that's needed to daemonize a process. So are we saying that we don't trust the kernel to reliably duplicate the state of file handles when we fork? No, you have it 180 degrees off. ;) Perhaps the sentence above should start So you are saying that I'm arguing that I should'nt have to perform a loop closing file descriptors I haven't opened. We *do* trust the kernel to reliably duplicate the state of file handles. This confirms above. So if we're about to do the whole double-fork thing and all that, we want to loop around and close all the file descriptors we don't want leaking to the double-forked daemon. Yes, we do something reasonable with fd 0,1,2 - but we probably also want to do something with that unclosed fd 3 that's still open on /etc/mydaemon.cf, and any other file descriptors we've left dangling in the breeze after initialization. Now this is a good point. I don`t do a double fork in autofs (inherited code), although, long ago I did. Do we really need to do a double fork to disassociate from the controlling terminal or is a single fork and close etc. enough? I notice that setsid() should do this but I've not seen it bofore. Is that sufficient to do the job instead of the double fork? And it looks like the automount process I just started still has a tty, grumble Ian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [autofs] automount does not close file descriptors at start
On Mon, 21 Feb 2005 12:57:22 +0800, Ian Kent said: > This is the first time I've heard this and the first time I wrote a Unix > daemon was fifteen years ago. > > As far as I'm concerned redirecting stdin, stdout and stderr to the null > device, then closing it and setting the process to a be the group leader > (as autofs does) should be all that's needed to daemonize a process. > > So are we saying that we don't trust the kernel to reliably duplicate the > state of file handles when we fork? No, you have it 180 degrees off. ;) We *do* trust the kernel to reliably duplicate the state of file handles. So if we're about to do the whole double-fork thing and all that, we want to loop around and close all the file descriptors we don't want leaking to the double-forked daemon. Yes, we do something reasonable with fd 0,1,2 - but we probably also want to do something with that unclosed fd 3 that's still open on /etc/mydaemon.cf, and any other file descriptors we've left dangling in the breeze after initialization. And yes, this sort of error happens in Real Live - I need to go and figure out why the /sbin/lvm.static on my initrd is throwing 'File descriptor 3 left open' messages... pgpwa9z1MK9uv.pgp Description: PGP signature
Re: [autofs] automount does not close file descriptors at start
On Wed, 16 Feb 2005, Steinar H. Gunderson wrote: > Hi, > > My latest autofs package for Debian (4.1.3+4.1.4beta2-1) had problems > installing, freezing after install; I've worked around this now > (4.1.3+4.1.4beta2-2 is on its way up to the archive), but I've been told this > is really a bug in automount. What I've been told is along the lines of: > > "Any daemon going into the background should close all file descriptors from > zero up to MAXFDS minus the ones it actually wants to have open." > > In other words, one should probably have a for loop of sorts in > become_daemon(). Steinar, I'm still wondering where this came from? This is the first time I've heard this and the first time I wrote a Unix daemon was fifteen years ago. As far as I'm concerned redirecting stdin, stdout and stderr to the null device, then closing it and setting the process to a be the group leader (as autofs does) should be all that's needed to daemonize a process. So are we saying that we don't trust the kernel to reliably duplicate the state of file handles when we fork? If that's the case then the kernel is badly broken and needs fixing, not autofs! Ian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [autofs] automount does not close file descriptors at start
On Wed, 16 Feb 2005, Steinar H. Gunderson wrote: Hi, My latest autofs package for Debian (4.1.3+4.1.4beta2-1) had problems installing, freezing after install; I've worked around this now (4.1.3+4.1.4beta2-2 is on its way up to the archive), but I've been told this is really a bug in automount. What I've been told is along the lines of: Any daemon going into the background should close all file descriptors from zero up to MAXFDS minus the ones it actually wants to have open. In other words, one should probably have a for loop of sorts in become_daemon(). Steinar, I'm still wondering where this came from? This is the first time I've heard this and the first time I wrote a Unix daemon was fifteen years ago. As far as I'm concerned redirecting stdin, stdout and stderr to the null device, then closing it and setting the process to a be the group leader (as autofs does) should be all that's needed to daemonize a process. So are we saying that we don't trust the kernel to reliably duplicate the state of file handles when we fork? If that's the case then the kernel is badly broken and needs fixing, not autofs! Ian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [autofs] automount does not close file descriptors at start
On Mon, 21 Feb 2005 12:57:22 +0800, Ian Kent said: This is the first time I've heard this and the first time I wrote a Unix daemon was fifteen years ago. As far as I'm concerned redirecting stdin, stdout and stderr to the null device, then closing it and setting the process to a be the group leader (as autofs does) should be all that's needed to daemonize a process. So are we saying that we don't trust the kernel to reliably duplicate the state of file handles when we fork? No, you have it 180 degrees off. ;) We *do* trust the kernel to reliably duplicate the state of file handles. So if we're about to do the whole double-fork thing and all that, we want to loop around and close all the file descriptors we don't want leaking to the double-forked daemon. Yes, we do something reasonable with fd 0,1,2 - but we probably also want to do something with that unclosed fd 3 that's still open on /etc/mydaemon.cf, and any other file descriptors we've left dangling in the breeze after initialization. And yes, this sort of error happens in Real Live - I need to go and figure out why the /sbin/lvm.static on my initrd is throwing 'File descriptor 3 left open' messages... pgpwa9z1MK9uv.pgp Description: PGP signature
