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

[Mike Rylander]

On 6/28/07, Scott McKellar <mck9 at swbell.net> wrote:
>
> --- Mike Rylander <mrylander at gmail.com> wrote:
>
> <snip>
>
> > To that end, I propose that we forcibly close stdin, stdout and
> > stderr
> > inside libopensrf/utils.c:daemonize() after calling setsid().  This
> > will require some more checks in the logging code to make sure that
> > stderr is still around for logging, and if not ... well, like Scott
> > said, the admin is a poo-poo head for not providing either a log file
> > or the required syslog info, and the message will be lost.  Logging
> > directly to stderr from within an opensrf application will also
> > obviously do nothing in this case.
>
> <snip>
>
> By "more checks in the logging code" I think you mean something like
> the following additions to log.c:
>
> static int osrfStderr = 1;
>
> void osrfStderrOff( void ) {
>     osrfStderr = 0;
> }
>
> Then every write to stderr would be wrapped like this:
>
>     if( osrfStderr ) {
>         fprintf( stderr, ... )
>     }

Right.  After looking at the man page, it seems that fprintf will just
return a negative value in the case of an error ... so we may not even
need to care about that, and no harm done, but belt-and-suspenders is
probably best.

>
> daemonize() would call osrfStderrOff() when it closes stderr.  We
> could also provide a function osrfStderrOn(), for complete symmetry,
> but I'm not sure that it would ever make sense to call it.
>

I don't think we need to worry about that ... how would one reopen
stderr anyway?  (It may be possible, but I've no idea how, and I don't
think the hoops are necessary.)

> I'd submit this notion in the form of a patch, but there's another
> patch still outstanding on log.c.  I want to see that one resolved
> first, because it adds an fprintf() to stderr.
>

ah HA ... there sure was.  Well, it was half of a patch -- the header
file had already been updated.  Which leads us to ...

The discovery of a breakdown in our submission workflow.  I think the
fix for this breakdown will actually allow you to simplify your
development process.

Currently, we're asking for context diffs based on a clean checkout
against a parallel, modified tree.  I think that's too much work on
both ends, and it leads to patch sets instead of single patch files.

I think a better process would be a simple

 $ svn update
 $ svn diff > patch.file.name

from the root of your repository working directory.  This won't be a
context diff, but that's OK, because we get the benefit of a single
patch file which, for everything but enormous changes, is much easier
for me to manage.  I will endeavor to correct the contribution
documentation to say as much.

> Alternatively there might be a way for log.c to determine whether
> the process was attached to a terminal, and either write or not
> write to stderr accordingly.  I don't know how that would work, nor
> whether it would work at all.

It doesn't feel portable, even among different distributions of Linux.
 I think your proposed approach is best.

--miker

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