Requirements 
 License 

 Installation 
 IRC usage 
 Server connects 
 DCC sends 
 Logging 

 Format 
 Reference 
 Example 

 Roadmap 
 Download 
 Config parser 
 Visions & ideas 

Logging

When certain events occur, MetalServe (and the supporting utilities, eg. makelist) can generate quite a number of log messages so you can keep track afterwards of what happened at a given moment in time. This is important as MetalServe itself runs as a non-interactive standalone daemon, without user control.^[1]. This section deals with all aspects related to logging.

• Severity levels
• Logging destination
• Interpreting the logfile

MetalServe's logging system is related to the standard logging facility on UNIX systems, syslogd. Each log message generated by MetalServe is associated with a severity level, which indicates how important the message is. MetalServe uses the following subset of syslogd's priority levels^[2], in ascending order of verbosity:

Severity	Description	Example
critical	Critical error conditions that force MetalServe to terminate	No configuration file
error	Error conditions that severly affect MetalServe's operation	An IRC network was disabled because all servers failed
warning	Error conditions that do not affect MetalServe's operation too severly	The filelist could not be compressed, but MetalServe was configured to offer both the compressed and the uncompressed version
notice	Notices / messages that are more than just informational	An IRC server was connected
info	Messages that are of a purely informational nature	The DCC send of a file to a user begins
debug	Debugging messages	The status of the poll() file descriptor array

While you can not enable or disable the logging of a certain message, you can control the amount of messages logged by specifying a minimum threshold for the severity level using the loglevel directive. Any message whose severity is lower than the severity level specified here is discarded.

For example, setting loglevel to notice will yield a good compromise for verboseness and logfile growth (which is why this is the default level). Increasing the loglevel to info allows you to follow MetalServe's operation more precisely. Specifying a severity level lower than warning is a bad idea, yet MetalServe, being a true fellow of UNIX philosophy, won't keep you from shooting yourself in the foot :-)

Logging destination

The destination of the log messages can be configured using the logfile directive, whose argument can be:

• a filename to write the log messages to,

• the special keyword syslog, optionally followed by a colon (':') and the syslog facility to log to (we'll discuss this in just a minute),

• or the special keyword none, which effectively disables logging (bad idea).

If you do not need remote logging, however, and you wish to avoid the problem of the scarce localX syslog facilities you can simply specify a filename directly. MetalServe will then append its log messages to this file without the need for a running syslog daemon. The default filename is /var/log/metalserve.log.

Note that you must make sure that MetalServe actually has the permissions to write to this file. However making the file world-writable is the wrong approach, instead create the file manually and have it owned by the same user MetalServe will run as, eg. as root execute:

touch /var/log/metalserve.log
chmod 0700 /var/log/metalserve.log
chown myname /var/log/metalserve.log

As with all log files, you should keep an eye on its size and use appropriate mechanisms, eg. logfile archival or logfile rotation. On a SuSE Linux system you could add an appropriate entry to the /etc/logfiles file.

Specifying none as logfile disables all logging and is a bad idea (did I already mention it's a bad idea?).

Interpreting the logfile

The MetalServe logfile format resembles the format syslog creates:

[Oct 25 18:05:50] makelist: makelist [MetalServe v0.1] started

Each line contains the timestamp the message was generated and the name of the program that generated the message (metalserved, makelist etc.). In this case we see the startup message of makelist, together with the associated MetalServe release version number (the single components do not have version numbers of their own, instead they carry a common version number, just like GNU ls's version number is the "fileutils" version number).

If the loglevel debug is specified, the format looks a little bit different:

[Oct 25 18:05:50] makelist: (main.c : main : 938) makelist [MetalServe v0.1] started

In debug mode, the actual log message is prefixed with a triplet consisting of:

• the source file name of the current function,
• the name of the current function,
• and the line number inside this file where the log message was generated.