Bugzilla – Bug 4208
gridftp server segfaults if it can't open its logfile
Last modified: 2006-04-14 14:06:02
You need to
before you can comment on or make changes to this bug.
The gridftp server will segfault if told to log to a file it can't open for
In the case I'm seeing, the fopen() at globus_i_gfs_log.c:222 fails and the
function returns without
setting globus_l_gfs_log_handle to a non-NULL value. The code then attempts to
globus_l_gfs_log_handle at the following point:
#0 0x08158690 in globus_logging_flush (handle=0x0) at globus_logging.c:298
#1 0x08051551 in globus_i_gfs_log_close () at globus_i_gfs_log.c:296
#2 0x08050a9e in main (argc=2, argv=0xbfe077a4)
Depending on the command-line arguments, it may catch the segv signal and exit
with status 11
Nothing is printed to stdout or stderr indicating that anything is wrong.
The segfault will be fixed for the coming 4.0.2 release. I'm not sure what I
want to do about reporting if the file can't be opened.
If the server is running under inetd, extraneous output will result in a failed
connection, which may not be desirable. Say there is a server that is set up
correctly and working, logging to an nfs mount, and that fs has problems down
the road... now the server is unusable. Whereas if I just silently ignore the
log error the server can continue normally but this will a) make initial setup
of logging harder to debug -- the logfile doesn't get written but there are no
errors -- or b) be bad in cases where logging is used for accounting/security
This is fixed for the upcoming 4.0.2 release.
I decided to only report the log file opening failure (to stderr) if the server
is not running under inetd, otherwise it silently fails and does not log.