[OPEN-ILS-DEV] srfsh woes

[Mike Rylander]

On 5/20/07, Scott McKellar <mck9 at swbell.net> wrote:
>
> --- Dan Scott <denials at gmail.com> wrote:
>
> > On 19/05/07, Scott McKellar <mck9 at swbell.net> wrote:
> > > What am I missing?
> > >
> > > I've been trying to compile and link a complete working copy of
> > > srfsh, but it's not reading the configuration file usefully.
>
> <snip>
>
> > > Is the sample configuration file on the Wiki really correct?
> >
> > Nope. Well, it wasn't, but now it is.
> >
> > Hope this helps!
>
> Yes it does.  Thank you.  I can load the new sample without
> incident, except of course that I had to change the path for the
> log file to something that existed on my machine.
>
> I also figured out, contrary to my earlier conclusions, that the
> bootstrap function returns zero for failure and non-zero for
> success, rather than the other way around.
>
> However the use of return codes is confusing and inconsistent.
>
> If the config file does not specify a log file, the
> osrf_system_bootstrap_client_resc function (or its wrapper function
> osrf_system_bootstrap_client()) returns -1, indicating a sort of
> success.  If the config file does specify a log file, and the
> bootstrapping is successful in other respects, the function returns
> 1, indicating complete success.
>
> In practice, the code that calls osrf_system_bootstrap_client_resc()
> or its wrapper does not distinguish between partial and complete
> success.  It just looks for zero or non-zero.
>
> In osrf_system_bootstrap_client_resc(): If we notice that the
> config file doesn't specify a log file, we issue an error message
> and return -1 immediately.  By so doing, we bypass the call to
> client_connect().  (We also leak memory, but that's another issue.)
>
> On the other hand if the config file does specify a log file, we
> proceed to call client_connect(), returning 1 if we connect
> successfully and 0 if we don't.
>
> The puzzling result is that if we get a successful (i.e. non-zero)
> return from osrf_system_bootstrap_client_resc(), we may or may not
> have created the connection, depending on whether the configuration
> specified a log file.
>
> Is that really the intent?

I believe a "partial success" result is actually intended (based on
how the Perl version of the logging component originally worked),
however, as you point out, it's not really success at all today.

The original design (and I haven't checked to see how much has
changed, though some definitely has) was to allow clients to send
output to stderr instead of requiring a log file.  I personally think
this would still be beneficial, but it would require some changes to
the logging code (certainly C, and probably Perl).

In order to require servers to have a log file configured we could
look at (getpid() - getsid()), and if it's nonzero we require a log
file under the (fairly reasonable) assumption that end-user clients
won't be calling daemonize(), or otherwise separating from their
parent process.  If they haven't called setsid() and don't have a log
file configured, then the logger can just send messages to stderr.

While I won't argue strongly for a "partial success" result here (were
the above changes made it would be full success), I can see the use in
having a "non-standard success", and perhaps even a mechanism
equivalent to errno to describe particular states.  I would think that
would be generally useful, but since we don't have it already (or
something like it) it's probably not needed.

Thoughts?

--miker

>
> I would have expected that, if we don't have a log file, we either
> return zero to indicate a fatal error, or try to connect anyway.
> It's not at all obvious why we should ever report success without
> even trying to connect.  Perhaps I just haven't gotten far enough
> along to discern the reason.
>
> Scott McKellar
> http://home.swbell.net/mck9/aargh/
>
>


-- 
Mike Rylander