[OPEN-ILS-DEV] Puzzling problem: cannot open

[Scott McKellar]

Dan:

I doubt that the recent changes to the C logging code are related to
your problem, but of course anything's possible.

The main point of those changes was to ensure that a logged message
will at least be written to standard error even if neither a log
file nor the syslog facility is available.  As long as you're using
a log file or the syslog, everything should happen just as it did 
before.  Even if you do write something extra to standard error, I 
wouldn't expect that to interfere with some other process's access 
to a file.

In any case, when log.c does write a message to a log file, it keeps
the file open just long enough to write the message, and then closes
it immediately.  Any contention should be brief and sporadic.

Since you refer to the fopen() in log.c, I assume that your config
file specifies a log file, rather than the syslog facility.  If you're
using syslog, then we have a different set of issues, and I don't
know enough about syslogging to address them.

Let me suggest another experiment.  Temporarily tinker with the 
config files so as to send messages to different log files from
different applications.  That should eliminate any contention for
the same log file.  If the problem goes away, then there must be a
problem with file access.  If not, not.

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

--- Dan Scott <denials at gmail.com> wrote:

<snip>
 
> Interestingly enough, /openils/var/log/osrfsys.log is open and being
> written to. So the obvious question is whether one of the recent
> logging changes is blocking attempts by Logger.pm to concurrently
> write to the log file (particularly now that both the C and Perl
> OpenSRF services both get their logfile name from opensrf_core.xml).
> 
> Tracking down the equivalent open method in the C services leads me
> to
> OpenSRF/trunk/src/libopensrf/log.c where we open the file with:
> 
> FILE* file = fopen(_osrfLogFile, "a");
> 
> I'm not 100% sure, but I _hope_ that mode "a" is non-blocking. Or
> perhaps we're going to have to look at using an equivalent open()
> call
> in log.c as well? If I wasn't so damned lazy I would just write a
> simple test C app and Perl app and test that hypothesis out on my own
> system.

<snip>