[OPEN-ILS-DEV] PATCH: osrfConfig.C (dropping stderr messages)

[Scott McKellar]

--- Mike Rylander <mrylander at gmail.com> wrote:

<snip -- about closing stdin, stdout, and stderr in daemonize(), etc>

I did a little research and got another idea out of a book
(Linux Application Development, by Johnson and Troan).

In daemonize(), the child process should indeed close stdin, stdout, 
and stderr.  But then it should reopen file descriptors 0, 1, and
2 to /dev/null.  That way any attempts to read or write these files
will do no harm.

In addition, reopening these file descriptors guarantees that we 
won't inadvertently reopen them for something else.  You wouldn't 
want to use file descriptor 2 for an output file and then find
yourself writing error messages to it. 

With this approach we wouldn't have to make any special provisions
in log.c, nor would we have to ruthlessly seek out and destroy all
references to stderr.  Anything we write to stderr will go directly
into the bit bucket.

The book also says that, before forking, the parent process should
change directories, either to the root directory or to some other 
suitable directory, and close all unneeded file descriptors.

If you don't change directories, then you can't delete that directory
until the program terminates.  That could create some occasional
inconvenience for no reason.

The reason to close unneeded file descriptors is that otherwise the
child process will inherit open file descriptors to which it may not
be entitled.  

I'm not sure what to do if the parent needs to keep a file descriptor
open while denying it to the child.  The simplest thing to do would
be to close everything with fcloseall(), and then reopen anything
you need.  

However there are cases where that doesn't work.  For example the 
parent might have opened a file and then deleted it from the file
system, while keeping it open.  That's a typical way to create a
temporary file that no other process can access.  But once the file
is closed, you can't get it back, because the OS has removed it from
the file system and reclaimed the disk space.  These issues will
probably need to be addressed on a case by case basis.

Scott McKellar
http://home.swbell.net/mck9/ct/