Bugzilla – Bug 1934
Gatekeeper's syslog output cannot be controlled
Last modified: 2012-01-06 11:03:56
You need to
before you can comment on or make changes to this bug.
The pre-web services gatekeeper logs to two places: a user-defined log file,
and syslog. There is no way to turn off output to syslog without turning off
all logging. (This is true in Globus 3.2.1 and Globus 2.4.3.)
Here is the relevant code (I added the two comments with //)
//Turning off all logging:
if ((strncmp(logfile, "logoff", 6) == 0) ||
(strncmp(logfile, "LOGOFF", 6) == 0))
/* no logging will be done, even syslog */
fprintf(stderr, "No logging will be done, even syslog.\n");
logging_syslog = 0;
logging_usrlog = 0;
//Forcing syslog to be on in other cases:
* By default open syslogfile if it is not open already.
* All messages will have GRAM gatekeeper and include the PID.
* The messages will be treated like any other system daemon.
logging_syslog = 1;
openlog("GRAM gatekeeper", LOG_PID, LOG_DAEMON);
I create the Virtual Data Toolkit (VDT), and we have users that are unhappy
with this behavior. This is because when a ton of jobs are submitted, their
system logs fill up and rotate very quickly. They would be completely content
with the globus-gatekeeper.log and don't want syslogging for the gatekeeper.
I propose that the gatekeeper should have one, perhaps two changes.
1) The addition of a -nosyslog option, which will cause no output to go to the
2) The addition of a -syslogfacility <facility> option which allows users to
change which syslog facility is used. Instead of "daemon", they can use LOCAL0
(or whatever) in order to get syslog() output that they can control through
the syslog.conf file. Since the daemon facility is likely to be used by other
programs, it's nice to allow users to select a different facility.
I would be completely content with #1. #2 would be even better, but it's not
as important as #1.
What do you think? Is an update for Globus 3.2.1 possible?
a gatekeeper update to 3.2.1 is possible. Option #1 seems simple enough. We
are focussed on a GT4
coding deadline, so we will not be able to get this done for a few weeks.
With the current work happening on GRAM 5, maybe this can be addressed?
Ok - thanks for pointing this out. Yea, this would make sense to look at.
I'll add it to the work queue. But it is unscheduled at present.
I just ran across this issue again, because the latest
lcas-lcmaps-gt4-interface globus callout is now supporting syslog and it has an
environment variable to control the logging facility, $LLGT_LOG_FACILITY. I
can send its logs then to another file, but the GRAM-gatekeeper messages still
all go to LOG_DAEMON. What I would like to see is a
$GLOBUS_GATEKEEPER_LOG_FACILITY environment variable, which we could set where
we set $GLOBUS_GATEKEEPER_LOG now.
I added a jira issue for this for scheduling for it to be worked on.
See http://jira.globus.org/browse/GRAM-303 for resolution and source tarballs.