Scheduler's log_events

Owned by Bhroam A Mann
Last updated: Sept 25, 2019
3 min read

Follow the PBS Pro Design Document Guidelines.

Overview

Right now, the different daemons log events differently.  The mom and server have log_events which you turn on which log bits you want to log.  The scheduler has a log_filter which you start with all bits and set which bits you want filtered out.  This RFE is to make the scheduler more like the other daemons.


Technical Details

New sched object attribute: log_events

This attribute will work similarly to server's log_events attribute, mom's $log_events config parameter, or the comm's PBS_COMM_LOG_EVENTS.  The value will be a decimal bitmask (e.g., 511 = all bits under 512). 

Since it is a sched attribute, each scheduler can have their own value of the log_events attribute.  The bits correspond to log events will be the events that are logged.

The default value of log_events is 767 (0x2FF).  This is the current default in log_events form.  If log_events is unset, it will be reset back to the default.

The default includes:

PBSEVENT_ERROR
PBSEVENT_SYSTEM 
PBSEVENT_ADMIN 
PBSEVENT_JOB 
PBSEVENT_JOB_USAGE 
PBSEVENT_SECURITY 
PBSEVENT_SCHED
PBSEVENT_DEBUG
PBSEVENT_RESV

This leaves out:

PBSEVENT_DEBUG2 
PBSEVENT_DEBUG3 
PBSEVENT_DEBUG4 

Internals:

The scheduler queries the its sched object on the first cycle.  It will use data from this query to set things like its log or priv directory.  It will also requery this data when that scheduler is sent a SCH_ATTRS_CONFIGURE command.  The log_events will be yet another thing queried from the sched object.  Once we have the log_events, we will set the 'log_event_mask' global variable to the value.  This global is used by the logging library to determine which events to log.  The scheduler's internal schdlog() function will replaced with calls to log_eventf() (see below).

Obsoleted sched_config parameter: log_filter

The log_filter sched_config parameter will be obsoleted. 

The following message will be logged if log_filter is in the sched_config file: "Obsolete config name log_filter, instead use nothing - set log_events via qmgr."

This message is printed when the scheduler is started and on a HUP.

This message is similar to the obsolete message for other sched_config parameters which were moved to qmgr.

New internal liblog function: void log_eventf(int eventtype, int objclass, int sev, const char *objname, const char *fmt, ...)

This new log event function is a combination of log_event() and sprintf().  The main purpose of this function is to eliminate all string manipulation for log messages that will ultimately be ignored because we're not logging that event.  This is important for the scheduler since it needs to avoid as much string manipulation as possible to be as fast as possible.


To implement this new function, pbs_asprintf() will be broken into three pieces.  Two of these pieces are internal helper functions.  The functionality of pbs_asprintf() will not be changed.

Function: int pbs_asprintf_len(const char *fmt, va_list *args):

This function will determine the length of the formatted string which is passed to pbs_asprintf().  The args parameter are the variable list arguments passed into pbs_asprintf().

Function: char *pbs_asprintf_format(int len, const char *fmt, va_list *args):

This function allocates the new buffer, and formats the string into the buffer.  The args parameter here is also the variable list arguments passed into pbs_asprintf().


pbs_asprintf() will now call pbs_asprintf_len() and then pass that length into pbs_asprintf_format() to get the string it will return.


log_eventf() has a local char * variable of the same length as log_buffer (4096).  It would probably be safe to use log_buffer, but to be on the safe side, we'll use a local variable.

log_eventf() will do the following:

  1. Call will_log_event() to determine if we are going to log the event.  If we aren't return.
  2. vsnprintf() into a local log buffer the same size as the global log_buffer.
  3. If we truncated the string, call pbs_asprintf_format()
  4. We call log_record() to to log the buffer.
  5. If we allocated the buffer with pbs_asprintf_format(), we free the buffer.


The reason we directly vsnprintf() into a buffer instead of calling pbs_asprintf_len() is that the vast majority of the log messages we log in PBS will fit.  Why should we call vsnprintf() twice for all messages, when we can get away with calling it only once for the majority of them.  It is true that really long log messages will take longer since we create the string twice, but those are few and far between.


OSS Site Map

Project Documentation Main Page

Developer Guide Pages