Documentation of the Logging and Debugging API for NTP

Related Topics:

Config file format

logging show
logging show N
logging clear
logging clear N


  • logging show displays the current active logging "slots"
  • logging show N displays the contents of logging slot N
  • logging clear resets all logging slots
  • logging clear N resets the contents of logging slot N
    • N - a number, like what we do for the crypto keys
    • SYSLOG - syslog FACILITY
      • FACILITY - {auth,authpriv,console,daemon,ntp,local0,local1,...,local7}
    • FILE - file /path [VERSIONS] [SIZE] (Does it have to be a rooted path?)
      • VERSIONS - versions ( NUMBER | unlimited ) (could be done later)
      • SIZE - size SIZESPEC (could be done later)
    • STDERR - stderr
    • WHAT - a tag and optionally a level


This should be relatively easy to dump this info with the saveconfig directive of ntpq.

The list above should be sufficiently useful to be good with its :config directive, too.

path : According to me, Rooted path shall be better... stdout : It shall be good if we implement this...Because in logging to terminal...I am logging to stdout when level is less than ERROR and to stderr if level is ERROR or more..

This way we will have only to include a category in the relevant channel's line than create an altogether new line for a new category.

-- RajulSrivastava - 2012-08-09

I think that if somebody says "send TAG to PLACE" that's where they want it to go, and not have the PLACE change because of the LEVEL.

-- HarlanStenn - 2012-08-10


Data Structures for Config Saving

A Log can be sent to a File, Syslog, or stderr.

So, the possible logging channels are

  • FILE

The logging channels take up parameters

  • FILE : path to the logging file
  • SYSLOG : name of the SYSLOG FACILITY
  • STDERR : stderr

The corresponding to each combination of channel_type and channel_parameters, there shall be a list of tags that are to be logged

The data structure that I have in mind is like the following

A structure for a logging channel with members Logging Channel, Channel Parmeters, A linked list of tags, that shall be a linked list on its own, that are to be logged, corresponding to that channel.

#define CHANNEL_FILE 1

// HMS: How about using an enum instead?

typedef struct {
    char *category;
    LoggingTagsList *next;
} LoggingTagsList;

typedef struct {
    int channel_type;
    int channel_number;
    char *channel_parameter;
    LoggingTagsList categories;
    LoggingChannel *next;
} LoggingChannel;

And then when we enconter a tag, we can look it up in the channels' structures and log it accordingly if found.

Another alternative that can be used is that, we have separate structures for SYSLOG channels, FILE channels, and STDERR channels (rather than having a linked list of all the channels and storing all types in one structure)

typedef struct {
    char *tag;
    LoggingTagsList *next;
} LoggingTagsList;

typedef struct {
    int channel;
    char *channel_parameter;
    LoggingTagsList tags;
    LoggingChannel *next;
} LoggingChannel;

LoggingChannel syslog_channels; // First Syslog Channel

LoggingChannel log_file_channels; // First FILE Channel

LoggingChannel stderr_channels; // STDERR Channel

This way when a message with some tags are to be logged to a particular kind of channel then only the linked list corresponding to that type of channel is traversed and we get to save processing cost.


The API calls shall be needed to - add new entries - change existing entries - look up entries - delete/clear entries

So, in the above data structure being a linked lists all these operations shall be quite easy..

-- RajulSrivastava - 2012-08-10

I think we may want the first form, not the 2nd. Otherwise we have to do extra work to make sure the specified channel number is not in any of the "other" lists.

-- HarlanStenn - 2012-08-11

Also, when processing a line of output we have to search all of the channels anyway - I don't see the benefit in separating the channels.

-- HarlanStenn - 2012-08-11

We should also have a member 'int number_of_tags' for each channel....Then, if the number of tags is 0, then it implies that there are no tags specified for the channel, and hence by default it shall log all the tags...However, we may also have a boolean variable for this like "log_all_tags"....

-- RajulSrivastava - 2012-08-12

So, this way, when we initialize a channel, a struct node is created....with members......channel_type : {SYSLOG, FILE, STDERR }, channel_number, channel_parameter, number_of_tags = 0, and empty linked list for allowed_tags.......and then if while going through the config file...statements binding tags to a channel are encountered...then the the number_of_tags and the linked list allowed_tags are updated....

-- RajulSrivastava - 2012-08-12

I'm not sure there is a need for number_of_tags - we have to follow the linked list pretty much no matter what we are doing...

-- HarlanStenn - 2012-08-13


This topic: Dev > WebHome > GoogleSummerOfCode > GSoC2012LoggingDebugging > GSoC2012LoggingDebuggingDocumentation
Topic revision: r10 - 2012-08-13 - 06:53:40 - HarlanStenn
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback