Bugzilla – Bug 1934
Gatekeeper's syslog output cannot be controlled
Last modified: 2012-01-06 11:03:56
You need to log in 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; } else //Forcing syslog to be on in other cases: { if (!logging_syslog) { /* * 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 syslog. 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? -alain
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? -alain
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. - Dave
I added a jira issue for this for scheduling for it to be worked on. http://jira.globus.org/browse/GRAM-303
See http://jira.globus.org/browse/GRAM-303 for resolution and source tarballs.