System log file analysis is one of the most important tasks when analyzing
the system. In fact, looking at the system log files should be the first
thing to do when maintaining or troubleshooting a system. openSUSE Leap
automatically logs almost everything that happens on the system in detail.
Since the move to systemd
, kernel messages and messages of system
services registered with systemd
are logged in systemd
journal
(see Book “Reference”, Chapter 11 “journalctl
: Query the systemd
Journal”). Other log files (mainly those of
system applications) are written in plain text and can be easily read
using an editor or pager. It is also possible to parse them using scripts.
This allows you to filter their content.
/var/log/
#
System log files are always located under the
/var/log
directory. The following list presents an
overview of all system log files from openSUSE Leap present after a
default installation. Depending on your installation scope,
/var/log
also contains log files from other services
and applications not listed here. Some files and directories described
below are “placeholders” and are only used, when the
corresponding application is installed. Most log files are only visible
for the user root
.
apparmor
AppArmor log files. See Book “Security Guide” for details of AppArmor.
audit
Logs from the audit framework. See Book “Security Guide” for details.
ConsoleKit/*
Logs of the ConsoleKit
daemon
(daemon for tracking what users are logged in and how they interact
with the computer).
cups/
Access and error logs of the Common Unix Printing System
(cups
).
faillog
Database file that contains all login failures.
firewall
Firewall logs.
gdm/*
Log files from the GNOME display manager.
krb5
Log files from the Kerberos network authentication system.
lastlog
A database containing information on the last login of each user. Use
the command lastlog
to view. See man 8
lastlog
for more information.
localmessages
Log messages of some boot scripts, for example the log of the DHCP client.
mail*
Mail server (postfix
,
sendmail
) logs.
messages
This is the default place where all Kernel and system log messages go
and should be the first place (along with
/var/log/warn
) to look at in case of problems.
NetworkManager
NetworkManager log files.
news/*
Log messages from a news server.
ntp
Logs from the Network Time Protocol daemon
(ntpd
).
pk_backend_zypp
PackageKit (with libzypp
back-end) log files.
puppet/*
Log files from the data center automation tool puppet.
samba/*
Log files from Samba, the Windows SMB/CIFS file server.
warn
Log of all system warnings and errors. This should be the first place
(along with the output of the systemd
journal) to look in case of
problems.
wtmp
Database of all login/logout activities,
and remote connections. Use the command last
to
view. See man 1 last
for more information.
xinetd.log
Log files from the extended Internet services daemon
(xinetd
).
Xorg.0.log
X.Org start-up log file. Refer to this in case you have problems starting X.Org. Copies from previous X.Org starts are numbered Xorg.?.log.
YaST2/*
All YaST log files.
zypp/*
libzypp
log files. Refer to
these files for the package installation history.
zypper.log
Logs from the command line installer zypper
.
To view log files, you can use any text editor. There is also a simple YaST module for viewing the system log available in the YaST control center under
› .
For viewing log files in a text console, use the commands
less
or more
. Use
head
and tail
to view the beginning
or end of a log file. To view entries appended to a log file in real-time
use tail
-f
. For information about
how to use these tools, see their man pages.
To search for strings or regular expressions in log files use
grep
. awk
is useful for parsing and
rewriting log files.
logrotate
#
Log files under /var/log
grow on a daily basis and
quickly become very large. logrotate
is a tool that
helps you manage log files and their growth. It allows automatic
rotation, removal, compression, and mailing of log files. Log files can
be handled periodically (daily, weekly, or monthly) or when exceeding a
particular size.
logrotate
is usually run as a daily cron
job,
and thus usually modifies log files only once a day. However, exceptions
occur when a log file is modified because of its size, if
logrotate
is run multiple times a day, or if
--force
is enabled.
The main configuration file of logrotate
is
/etc/logrotate.conf
. System packages and
programs that produce log files (for example,
apache2
) put their own
configuration files in the /etc/logrotate.d/
directory. The content of /etc/logrotate.d/
is
included via /etc/logrotate.conf
.
/etc/logrotate.conf
## see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # use date as a suffix of the rotated file dateext # uncomment this if you want your log files compressed #compress # comment these to switch compression to use gzip or another # compression scheme compresscmd /usr/bin/bzip2 uncompresscmd /usr/bin/bunzip2 # RPM packages drop log rotation information into this directory include /etc/logrotate.d
The create
option pays heed to the modes and
ownerships of files specified in /etc/permissions*
.
If you modify these settings, make sure no conflicts arise.
logrotate
is controlled through cron
and is
called daily by /etc/cron.daily/logrotate
. Use
/var/lib/logrotate.status
to find out when a
particular file has been rotated lastly.
logwatch
#
logwatch
is a customizable, pluggable log-monitoring
script. It parses system logs, extracts the important information and
presents them in a human readable manner. To use
logwatch
, install the
logwatch
package.
logwatch
can either be used at the command line to
generate on-the-fly reports, or via cron
to regularly create custom
reports. Reports can either be printed on the screen, saved to a file, or
be mailed to a specified address. The latter is especially useful when
automatically generating reports via cron
.
On the command line, you can tell logwatch
for which
service and time span to generate a report and how much detail should be
included:
# Detailed report on all kernel messages from yesterday logwatch --service kernel --detail High --range Yesterday --print # Low detail report on all sshd events recorded (incl. archived logs) logwatch --service sshd --detail Low --range All --archives --print # Mail a report on all smartd messages from May 5th to May 7th to root@localhost logwatch --service smartd --range 'between 5/5/2005 and 5/7/2005' \ --mailto root@localhost --print
The --range
option has got a complex syntax—see
logwatch
--range help
for details. A
list of all services that can be queried is available with the following
command:
ls /usr/share/logwatch/default.conf/services/ | sed 's/\.conf//g'
logwatch
can be customized to great detail. However,
the default configuration should usually be sufficient. The default
configuration files are located under
/usr/share/logwatch/default.conf/
. Never change them
because they would get overwritten again with the next update. Rather
place custom configuration in /etc/logwatch/conf/
(you may use the default configuration file as a template, though). A
detailed HOWTO on customizing logwatch
is available at
/usr/share/doc/packages/logwatch/HOWTO-Customize-LogWatch
.
The following configuration files exist:
logwatch.conf
The main configuration file. The default version is extensively commented. Each configuration option can be overwritten on the command line.
ignore.conf
Filter for all lines that should globally be ignored by
logwatch
.
services/*.conf
The service directory holds configuration files for each service you can generate a report for.
logfiles/*.conf
Specifications on which log files should be parsed for each service.
logger
to Make System Log Entries #
logger
is a tool for making entries in the system log.
It provides a shell command interface to the rsyslogd system log module.
For example, the following line outputs its message in
/var/log/messages
or directly in the journal (if no
logging facility is running):
logger -t Test "This messages comes from $USER"
Depending on the current user and host name, the log contains a line similar to this:
Sep 28 13:09:31 venus Test: This messages comes from tux