How to View and Configure Linux System Logs on Ubuntu 20.04
This tutorial explains the basic administration of a Linux server through system logs. A system log is a file that contains information about the events that happened on the system during runtime.
In this article, you will learn the following Linux logging basics:
- Where the Linux log files are stored, how are they formatted, and how to read them.
- How to read the most important logs (such as syslog ).
- How to configure the Ubuntu syslog daemon.
- What Linux log rotation is all about and how to use the logrotate utility.
Prerequisites
Before proceeding with the rest of this tutorial, ensure that you have a basic knowledge of working with the Linux command line. While many of the concepts discussed in this article are general applicable to all Linux distributions, we’ll be demonstrating them in Ubuntu only so ensure to set up an Ubuntu 20.04 server that includes a non-root user with sudo access.
🔭 Want to centralize and monitor your Linux logs?
Head over to Logtail and start ingesting your logs in 5 minutes.
Step 1 — Finding Linux system logs
All Ubuntu system logs are stored in the /var/log directory. Change into this directory in the terminal using the command below:
You can view the contents of this directory by issuing the following command:
You should see a similar output to the following:
alternatives.log auth.log btmp cloud-init-output.log dmesg dpkg.log journal/ landscape/ private/ ubuntu-advantage-license-check.log ubuntu-advantage-timer.log unattended-upgrades/ apt/ bootstrap.log cloud-init.log dist-upgrade/ dmesg.0 faillog kern.log lastlog syslog ubuntu-advantage.log ufw.log wtmp
Let’s look at a few of the essential system log files that may be present in the /var/log directory and what they contain:
- /var/log/syslog : stores general information about any global activity in the system.
- /var/log/auth.log : keeps track of all security-related actions (login, logout, or root user activity).
- /var/log/kern.log : stores information about events originating from the Linux kernel.
- /var/log/boot.log : stores system startup messages.
- /var/log/dmesg : contains messages related to device drivers.
- /var/log/faillog : keeps track of failed logins, which comes in handy when investigating attempted security breaches.
The /var/log directory is also used to store various application logs. For example, if your distribution is bundled with Apache or MySQL, or installed later, their log files will also be found here.
Step 2 — Viewing Linux log file contents
Log files contain a large amount of information that are useful for monitoring or analyzing activities performed by the system or a specific application. Therefore, a Linux server administrator must learn the art of reading and understanding the various messages present in log files to effectively diagnose or troubleshoot an issue.
Before we can read log files, we ought to know how they are formatted. Let’s review two basic approaches to log file formatting and storage: plain text and binary files.
Plaintext log files
These logs are plain text files with a standardized content format. Ubuntu uses a log template called RSYSLOG_TraditionalFileFormat . This log format consists of four main fields with a space delimiter:
- The timestamp indicates the time when a log entry was created in the format MMM dd HH:mm:ss (e.g. Sep 28 19:00:00 ). Notice that this format does not include a year.
- Hostname is the host or system that originally create the message.
- Application is the application that created the message.
- Message contains the actual details of an event.
Let’s go ahead and review some log files in the plaintext format. Run the command below to print the contents of the /var/log/syslog file with the tail utility:
This outputs the last 10 lines of the file:
Mar 23 12:38:09 peter dbus-daemon[1757]: [session uid=1000 pid=1757] Activating via systemd: service name='org.freedesktop.Tracker1' unit='tracker-store.service' requested by ':1.1' (uid=1000 pid=1754 comm="/usr/libexec/tracker-miner-fs " label="unconfined") Mar 23 12:38:09 peter systemd[1743]: Starting Tracker metadata database store and lookup manager. Mar 23 12:38:09 peter dbus-daemon[1757]: [session uid=1000 pid=1757] Successfully activated service 'org.freedesktop.Tracker1' Mar 23 12:38:09 peter systemd[1743]: Started Tracker metadata database store and lookup manager. Mar 23 12:38:40 peter tracker-store[359847]: OK Mar 23 12:38:40 peter systemd[1743]: tracker-store.service: Succeeded. Mar 23 12:39:01 peter CRON[359873]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi) Mar 23 12:39:23 peter systemd[1]: Starting Clean php session files. Mar 23 12:39:23 peter systemd[1]: phpsessionclean.service: Succeeded. Mar 23 12:39:23 peter systemd[1]: Finished Clean php session files.
You’ll notice that that each record in this file is formatted in the manner described earlier. For example, the last record has its timestamp as Mar 23 12:39:23, hostname as peter, application as systemd[1] and message as Finished Clean php session files.
If you want to view the entire log file, you can use the cat utility or any text editor such as nano or vim .
Binary log files
While plaintext is the dominant storage format for log files, you will also encounter binary log files that cannot be read with a normal text editor. The /var/log directory contains multiple binary files that are related to the user authorization:
- /var/log/utmp : tracks users that are currently logged into the system.
- /var/log/wtmp : tracks previously logged in users. It contains a past data from utmp .
- /var/log/btmp : tracks failed login attempts.
For these binary logs, special command-line tools are used to display the relevant information in human-readable form. For example, to review the contents of the /var/log/utmp file, run the who utility with -H option (this option causes column labels to be printed in the output table):
syslog(3) — Linux man page
closelog() closes the descriptor being used to write to the system logger. The use of closelog() is optional.
openlog() opens a connection to the system logger for a program. The string pointed to by ident is prepended to every message, and is typically set to the program name. If ident is NULL, the program name is used. (POSIX.1-2008 does not specify the behavior when ident is NULL.)
The option argument specifies flags which control the operation of openlog() and subsequent calls to syslog(). The facility argument establishes a default to be used if none is specified in subsequent calls to syslog(). Values for option and facility are given below. The use of openlog() is optional; it will automatically be called by syslog() if necessary, in which case ident will default to NULL.
syslog() generates a log message, which will be distributed by syslogd(8). The priority argument is formed by ORing the facility and the level values (explained below). The remaining arguments are a format, as in printf(3) and any arguments required by the format, except that the two character sequence %m will be replaced by the error message string strerror(errno). A trailing newline may be added if needed.
The function vsyslog() performs the same task as syslog() with the difference that it takes a set of arguments which have been obtained using the stdarg(3) variable argument list macros.
The subsections below list the parameters used to set the values of option, facility, and priority.
option The option argument to openlog() is an OR of any of these: LOG_CONS
Write directly to system console if there is an error while sending to system logger.
Open the connection immediately (normally, the connection is opened when the first message is logged).
Don’t wait for child processes that may have been created while logging the message. (The GNU C library does not create a child process, so this option has no effect on Linux.)
The converse of LOG_NDELAY; opening of the connection is delayed until syslog() is called. (This is the default, and need not be specified.)
(Not in POSIX.1-2001 or POSIX.1-2008.) Print to stderr as well.
Include PID with each message.
facility The facility argument is used to specify what type of program is logging the message. This lets the configuration file specify that messages from different facilities will be handled differently. LOG_AUTH
security/authorization messages (private)
clock daemon (cron and at)
system daemons without separate facility value
kernel messages (these can’t be generated from user processes) LOG_LOCAL0 through LOG_LOCAL7
reserved for local use LOG_LPR
messages generated internally by syslogd(8) LOG_USER (default)
generic user-level messages LOG_UUCP
level This determines the importance of the message. The levels are, in order of decreasing importance: LOG_EMERG
action must be taken immediately
normal, but significant, condition
debug-level message The function setlogmask(3) can be used to restrict logging to specified levels only.
Conforming To
The functions openlog(), closelog(), and syslog() (but not vsyslog()) are specified in SUSv2, POSIX.1-2001, and POSIX.1-2008. POSIX.1-2001 specifies only the LOG_USER and LOG_LOCAL* values for facility. However, with the exception of LOG_AUTHPRIV and LOG_FTP, the other facility values appear on most UNIX systems. The LOG_PERROR value for option is not specified by POSIX.1-2001 or POSIX.1-2008, but is available in most versions of UNIX.
Notes
The argument ident in the call of openlog() is probably stored as-is. Thus, if the string it points to is changed, syslog() may start prepending the changed string, and if the string it points to ceases to exist, the results are undefined. Most portable is to use a string constant.
Never pass a string with user-supplied data as a format, use the following instead: