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

Bill Erickson billserickson at gmail.com
Fri Jun 29 09:36:44 EDT 2007


On 6/28/07, Mike Rylander <mrylander at gmail.com> wrote:
>
> On 6/28/07, Scott McKellar <mck9 at swbell.net> wrote:
> >
> > --- 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).
> >
>
> [snip]
>
> That is a solid plan.  If you're raising your hand then I'd love to
> see the patch.  I'd also like to get Bill's input, since this is his
> code we're beating about, but daemonization needs to be fixed up. */me
> pokes Bill*
>
> >
> > 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.
>
> Hmm... it's heavy-handed, but there's no reason not to do this based
> on the current code.  It would certainly eliminate potential confusion
> arising from open file handles.  Let's just make sure there's a
> comment next to the fcloseall that explains the caveats and the
> fclose-std* alternative.



I'm concerned about the fcloseall() approach.  Currently, we fork the
applications and application worker processes before the top-level process
calls daemonize().  The app processes communicate via pipes to their worker
children (which is something I'd like to re-design, but I'll save that
discussion for later), which, if I'm reading the man page for fcloseall()
correctly, will be closed by that system call.


-bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070629/7c1ce442/attachment-0001.html


More information about the Open-ils-dev mailing list