Logging
MythTV (starting with version 0.25) supports logging to various loggers. Logging to them is enabled with command-line arguments.
[fd1800a] removed the legacy --logfile
and -l
arguments.
Additional information about application command-line arguments is available using the --help
argument, for example:
mythbackend --help
or
mythfrontend --help
Detailed help information is available for each argument by including the argument name after --help
, for example:
mythbackend --help setloglevel mythbackend --help logpath
Contents
General
All logging (regardless of specified logger) is affected by the arguments:
--loglevel Set the logging level. All log messages at lower levels will be discarded. In descending order: emerg, alert, crit, err, warning, notice, info, debug defaults to info -v OR --verbose Specify log filtering. Use '-v help' for level info.
Typically, the default value for --loglevel
and --verbose
are appropriate for normal application execution. However, you may be asked to provide logs at a specific log level when helping debug issues.
Loggers
Console Logging
If running a MythTV application in a non-daemon mode, console logging will be enabled. Console logging is output to stdout
.
Console logging is automatically disabled with the argument:
--daemon OR -d Fork application into background after startup.
(for MythTV daemon applications).
The console logging output contains a shortened format which better fits a standard terminal. Therefore, please provide full file logging output when attaching log files to bug tickets.
File Logging
The primary logger for MythTV applications is the file logger. File logging outputs detailed "debug" logging information about process execution, which can be very useful in debugging issues with MythTV. All log files uploaded to bug tickets should be those created from the file logger.
File logging is disabled by default and may be enabled with the argument:
--logpath Writes logging messages to a file in the directory logpath with filenames in the format: applicationName.date.pid.log. This is typically used in combination with --daemon, and if used in combination with --pidfile, this can be used with log rotators, using the HUP call to inform MythTV to reload the file
File logging output may be challenging to read in a terminal due to the amount of information included. You may simplify the log file output with a log processor. For example, the command:
perl -pwe '$| = 1; s#^(\d{4}(?:-\d{2}){2} \d{2}(?:\:\d{2}){2}\.\d{6} \w) \[\d+/\d+\] \S+ \S+ \(\S+\) - (.*$)#$1 $2#' /path/to/logfile
will scan the log file at /path/to/logfile
and output (to stdout
) a simplified log format equivalent to that used by console logging. Change the /path/to/logfile
, as appropriate for your system.
If you'd like to log full details while following the log file in a console with the above simplification, use the tail command:
tail -f /path/to/logfile | perl -pwe '$| = 1; s#^(\d{4}(?:-\d{2}){2} \d{2}(?:\:\d{2}){2}\.\d{6} \w) \[\d+/\d+\] \S+ \S+ \(\S+\) - (.*$)#$1 $2#'
syslog Logging
Logging to syslog may be enabled with the argument:
--syslog Set the syslog logging facility. Set to "none" to disable, defaults to none
By default, logging to syslog is disabled. You should only enable syslog logging if you have also configured syslog on your host to handle the MythTV log messages appropriately.
Database Logging
Database logging is enabled by default. It may be disabled with the argument:
--nodblog Disable database logging.
MythTV automatically cleans up the database logging information, to ensure your database does not grow out of control. All database logging information is removed within 2 weeks, so database logging is primarily useful for short-term log access, and should not be considered a valid long-term logging mechanism.
Log file cleanup
You may configure external applications, such as logrotate or GNU Rottlog, to rotate your log files. These programs allow you to specify exactly how to handle the multiple log files--including how often to rotate, how many old log files to keep and how long to keep them, how to handle the old log files (where to place them and whether to compress them), and much more. Example configurations are available at Category:Log Rotation Configuration Files.
Alternatively, a python script, logcleanup.py, is available to manage the multiple copies of these logs generated each time the applications restart. With its default settings, it will keep a minimum of five sets of logs for each application, and each set will be kept a minimum of seven days. One log set is one file, along with any rotated, compressed copies generated by logrotate. This script can be set to run daily or weekly through cron.