MythTV (starting with version 0.25) supports logging to various loggers. Logging to them is enabled with command-line arguments. Additional information about application command-line arguments is available using the <code>--help</code> argument, for example:

+

Starting with version 0.26, all log requests are handled by [[Mythlogserver|mythlogserver]].

+

+

MythTV (starting with version 0.25) supports logging to various loggers. Logging to them is enabled with command-line arguments.

Additional information about application command-line arguments is available using the <code>--help</code> argument, for example:

mythbackend --help

mythbackend --help

Line 16:

Line 20:

All logging (regardless of specified logger) is affected by the arguments:

All logging (regardless of specified logger) is affected by the arguments:

−

--setloglevel Change logging level of the existing master

+

--loglevel Set the logging level. All log messages at

−

backend.

+

lower levels will be discarded.

−

--verbose OR -v Specify log filtering. Use '-v help' for level

+

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.

info.

−

Typically, the default value for <code>--setloglevel</code> and <code>--verbose</code> are appropriate for normal application execution. However, you may be asked to provide logs at a specific log level when helping debug issues.

+

Typically, the default value for <code>--loglevel</code> and <code>--verbose</code> are appropriate for normal application execution. However, you may be asked to provide logs at a specific log level when helping debug issues.

== Loggers ==

== Loggers ==

Line 43:

Line 50:

File logging is disabled by default and may be enabled with the argument:

File logging is disabled by default and may be enabled with the argument:

−

--logfile OR --logpath OR -l Writes logging messages to a file at logpath.

+

--logpath Writes logging messages to a file in the directory logpath with

−

If a directory is given, a logfile will be

+

filenames in the format: applicationName.date.pid.log.

−

created in that directory with a filename of

+

This is typically used in combination with --daemon, and if used

−

applicationName.date.pid.log.

+

in combination with --pidfile, this can be used with log

−

If a full filename is given, that file will be

+

rotators, using the HUP call to inform MythTV to reload the file

−

used.

+

−

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 (currently disabled).

+

−

+

−

When specifying a file path, file logging is only enabled for the application you are starting. All logging will be disabled for child processes started by that application (for example, preview generation, commercial detection, transcoding, and other jobs started by mythbackend). Therefore, you should always specify a directory as the argument for <code>--logpath</code> or <code>-l</code>.

+

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:

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:

Line 65:

Line 64:

If you'd like to log full details while following the log file in a console with the above simplification, use the tail command:

If you'd like to log full details while following the log file in a console with the above simplification, use the tail command:

This note should be removed or updated after <code>wget</code> is replaced.

+

−

}}

+

=== syslog Logging ===

=== syslog Logging ===

Line 93:

Line 84:

== Log file cleanup ==

== Log file cleanup ==

−

When using the old <code>--logfile /path/to/log_directory/''appname''.log</code> option, only those logs from that specific application will be written to the file. It is highly suggested to use the new <code>--logpath /path/to/log_directory</code> option, where each program and each child chooses its own log name inside that path, using the syntax:

+

You may configure external applications, such as [https://fedorahosted.org/logrotate/ logrotate] or [http://www.gnu.org/software/rottlog/ 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, where to place the log files, whether to compress them, and much more. Example configurations are available in the [[:Category:Log Rotation Configuration Files|Log Rotation Configuration Files category]].

−

''appname''.''date''.''pid''.log

+

−

Mythbackend and mythfrontend will be long running tasks, resulting in large log files for each. As such, it is recommended to run '''logrotate''', or some similar application to automatically cycle and compress those logs. Examples for the [[Logrotate - mythbackend|backend]] and [[Logrotate - mythfrontend|frontend]] can be found on this wiki.

+

Alternatively, a python script, [https://github.com/MythTV/packaging/blob/master/Gentoo/media-tv/mythtv/files/logcleanup.py 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.

−

Logrotate and similar applications will only handle each file individually, and will not understand the above naming scheme. A python script, [https://github.com/MythTV/packaging/blob/master/Gentoo/media-tv/mythtv/files/logcleanup.py 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.

+

[[Category:HOWTO]]

Revision as of 17:14, 28 August 2012

Starting with version 0.26, all log requests are handled by mythlogserver.

MythTV (starting with version 0.25) supports logging to various loggers. Logging to them is enabled with command-line arguments.
[fd1800a]cgitgithub 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:

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:

syslog Logging

--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, where to place the log files, whether to compress them, and much more. Example configurations are available in the Log Rotation Configuration Files category.

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.