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

[Mike Rylander]

On 6/29/07, Scott McKellar <mck9 at swbell.net> wrote:
>
> --- Bill Erickson <billserickson at gmail.com> wrote:
>
> > 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.
>
> In the case of daemonize() I'm inclined to agree.  Since the parent
> exits immediately, it doesn't need to keep any file descriptors open.
> The child should properly inherit all the file descriptors.  In fact
> I don't really understand why we fork at all instead of just doing a
> raw setsid().  I'm sure there's a reason, but I don't know what it
> is.

Regarding fcloseall(), it does not seem portable according to the man
page in any case. This* provides an alternative from 4.2BSD, and Linux
supports this as well.  We'll have to look at AIX, but getdtablesize()
is the only concern I have, and only because I don't have an AIX or
Solaris box to look at.

As for the fork, the reason is to orphan the process, and force its
parent to be init.  The setsid() just handles creating a new process
group for signaling.

* http://www.enderunix.org/docs/eng/daemon.php

Achtung!! Hmmm... Looking further, we'd probably be killing syslog if
we just used fcloseall() (or equivalent) all willy-nilly.  It looks
like freopen (C89, POSIX.1-990) is what we really want.

So ... to recap my current proposal:

daemonize() before the forker loop, and inside that:
  chdir /
  fflush(stderr)
  use freopen() to point std{in|out|err} at /dev/null
  fork()
  setsid()

> Another approach is to replace daemonize() with the Linux function
> daemon(), which seems to do everything we need.  Or we could
> implement daemonize() by calling daemon(), perhaps in a macro.
> However I don't know if daemon() is widely available in other unices.
> It originated in BSD, but may not be present in the AT&T lineage.
> At work I use AIX, and there is no man page for daemon.

I think this is a non-starter.  It looks like we've got enough
examples to create a solid implementation, and using our code even on
linux/bsd will force us to make sure it works well.

Thanks, guys.

--miker