LDM Logging
|
Copyright 2019 University Corporation for Atmospheric Research. All rights reserved. See the the file COPYRIGHT in the top-level source-directory for licensing conditions.
The logging component of the LDM comprises a single API with two implementations: one using a simple implementation and the other using the LDM's original ulog
module (that module is still part of the LDM library for backward compatibility with user-developed code). By default the simple implementation is used. The ulog
implementation will be used if the option --with-ulog
is given to the configure
script.
Unless otherwise stated, this documentation is primarily on the simple implementation rather than the ulog
implementation, which is documented elsewhere.
Both implementations manage a FIFO queue of log messages for each thread in a process. log_add*()
functions add to the queue. At some point, one of the following should occur:
log_flush_*()
functions (e.g., "log_flush_error()"); orlog_clear()
.By default, log messages are written to
ulog
implementation: The system logging daemon(Note that the LDM server, ldmd
, daemonizes itself by default. It is the only program that does.)
If the output destination is a file, then a USR1
signal sent to any LDM utility will cause this logging module to close and re-open the output file. This allows the log files to be rotated and purged by an external process so that the disk partition doesn't become full.
A USR2
signal sent to any LDM utility will cause the logging level to be "rotated" in the following sequence:
NOTICE -> INFO -> DEBUG -> NOTICE -> ...
Be advised that logging at the DEBUG
level will likely cause the log file to become very large, very quickly.
The default destination for log messages can usually be overridden by the command-line option -l
dest:
dest | Destination |
---|---|
"" | System logging daemon |
"-" | Standard error stream |
path | File whose pathname is path |
Here's a contrived example:
Log messages sent to either the standard error stream or the LDM log file by the simple implementation will have the following format:
time proc loc level msg
where:
20160121T163218.391847Z
). DEBUG
, INFO
, NOTE
, WARN
, or ERROR
. Log messages sent to the system logging daemon will, in general, have the same proc, loc, and msg components as above, but the time and level components will depend on the system logging daemon. Additionally, the system logging daemon might alter the order of the components and/or add additional components (e.g., the name of the local host).