Bug 1934 - Gatekeeper's syslog output cannot be controlled
: Gatekeeper's syslog output cannot be controlled
Status: RESOLVED FIXED
: GRAM
gt2 Gatekeeper/Jobmanager
: 3.2.1
: All All
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2004-09-22 15:47 by
Modified: 2012-01-06 11:03 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-09-22 15:47:27
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
------- Comment #1 From 2004-10-04 00:01:59 -------
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.
------- Comment #2 From 2009-05-14 21:57:26 -------
With the current work happening on GRAM 5, maybe this can be addressed?

-alain
------- Comment #3 From 2009-05-15 09:35:26 -------
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.
------- Comment #4 From 2011-12-29 15:44:10 -------
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
------- Comment #5 From 2011-12-31 15:35:09 -------
I added a jira issue for this for scheduling for it to be worked on.
http://jira.globus.org/browse/GRAM-303
------- Comment #6 From 2012-01-06 11:03:56 -------
See http://jira.globus.org/browse/GRAM-303 for resolution and source tarballs.