Lots of things happen on a Linux system while it's running. Part of your job as a Linux administrator is watching over all that is happening and watching for when things go wrong. The primary tools for accomplishing that task are the logging and journaling services.
All Linux distributions implement some method of logging. Logging or journaling directs short messages that indicate what events happen, and when they happen, to users, files, or even remote hosts for storage. If something goes wrong, the Linux administrator can review the entries in the log or journal to help determine the cause of the problem. Most logging methods allow manually entered messages, so local script utilities can create their own log and journal entries.
Managing the logging and journaling services is critical, and you need to understand the important aspects of maintaining the log and journal files, and their configurations. Configuring a system's method of logging is more than setting what is recorded. You'll also have to determine how large you'll allow log and journal files to get, when to remove journal files from the system, and whether to compress them beforehand. Administrators also need to protect their system's log and journal files, know where they are located in the virtual directory structure, and know how to sync them, when needed.
The systemd system services package includes the systemd‐journald journal utility for logging. Notice that we called it a journal utility instead of a logging utility. The systemd‐journald program uses its own method of storing event messages completely different from the older Linux logging protocol specifications.
This section discusses how to use the systemd‐journald program to track event messages on your Linux system.
The systemd‐journald service reads its configuration from the /etc/systemd/journald.conf configuration file. When you examine this file, you'll notice settings that control how the application works and controls items, such as the journal file's size. Table 15.1 describes commonly modified directives.
TABLE 15.1: The journald.conf File Commonly Modified Directives
| DIRECTIVE | DESCRIPTION |
|---|---|
Storage |
Set to auto, persistent, volatile, or none. Determines how systemd‐journald stores event messages. (Default is auto.) |
Compress |
Set to yes or no. If yes, journal files are compressed. (Default is yes.) |
ForwardToSyslog |
Set to yes or no. If yes, any received messages are forwarded to a separate syslog program, such as rsyslogd, running on the system. (Default is yes.) |
ForwardToWall |
Set to yes or no. If yes, any received messages are forwarded as wall messages to all users currently logged into the system. (Default is yes.) |
MaxFileSec |
Set to a number followed by a time unit (such as month, week, or day) that sets the amount of time before a journal file is rotated (archived). Typically, this is not needed if a size limitation is employed. To turn this feature off, set the number to 0 with no time unit. (Default is 1month.) |
RuntimeKeepFree |
Set to a number followed by a unit (such as K, M, or G) that sets the amount of disk space systemd‐journald must keep free for other disk usages when employing volatile storage. (Default is 15% of current space.) |
RuntimeMaxFileSize |
Set to a number followed by a unit (such as K, M, or G) that sets the amount of disk space systemd‐journald journal files can consume if it is volatile. |
RuntimeMaxUse |
Set to a number followed by a unit (such as K, M, or G) that sets the amount of disk space systemd‐journald can consume when employing volatile storage. (Default is 10% of current space.) |
SystemKeepFree |
Set to a number followed by a unit (such as K, M, or G) that sets the amount of disk space systemd‐journald must keep free for other disk usages when employing persistent storage. (Default is 15% of current space.) |
SystemMaxFileSize |
Set to a number followed by a unit (such as K, M, or G) that sets the amount of disk space systemd‐journald journal files can consume if it is persistent. |
SystemMaxUse |
Set to a number followed by a unit (such as K, M, or G) that sets the amount of disk space systemd‐journald can consume when employing persistent storage. (Default is 10% of current space.) |
Changing a journal file from being volatile to persistent is covered later in this chapter. Thus, the Storage directive settings in Table 15.1 need a little more explanation, because they are involved in this activity:
auto
: Causes systemd‐journald to look for the /var/log/journal directory and store event messages there. If that directory doesn't exist, it stores the event messages in the temporary /run/log/journal directory, which is deleted when the system shuts down.persistent
: Causes systemd‐journald to automatically create the
/var/log/journal directory if it doesn't currently exist, and store event messages there.volatile
: Forces systemd‐journald to store only event messages in the temporary /run/log/journal directory.none
: Event messages are discarded.There are quite a few settings that allow you to customize exactly how systemd‐journald works in your system. If you'd like to explore a full list and explanation of all the settings, type man journald.conf at the command‐line prompt.
You may have one or more active journal files on your system, depending on how systemd‐journald is configured. For example, if you have Storage set to persistent, you can employ the SplitMode directive to divide up the journal file into multiple active files—one per user as well as a system journal file.
The file(s) directory location is contingent on whether the journal is persistent. In either case, the system's active journal file is named system.journal, with user active journal files (if used) named user‐
UID
. journal.
These journal files are rotated automatically when a certain size or time is reached, depending on the directives set in the journal.conf file. After the files are rotated, they are renamed and considered archived. The archived journal filenames start with either system or user‐
UID
, contain an @ followed by several letters and numbers, and end in a .journal file extension.
Here is a snipped example of both active and archived journal files on an Ubuntu distribution:
$ ls /var/log/journal/97be830906c6403080531940216d9d58/system.journalsystem@0005b1a4fa2a3f11-ccebd7a67a3fac0e.journal~system@0005b1ba77b40dbf-746bd77e61dfd702.journal~system@0005b85104386367-0f9a91515ce90123.journal~system@2f6af80fdbf44d0d946eeed38d4d[…].journalsystem@2f6af80fdbf44d0d946eeed38d4d[…].journaluser-1000.journaluser-1000@3367a2ef66d648b498adedab8[…].journaluser-1000@ce192e7a8484423d8ad44e590[…].journaluser-1001.journal$
Notice that this system uses both system and user journal files and that several of the files have been archived. The systemd‐journald configuration dictates when the archived journal files are removed from the system based on size directives, such as SystemMaxFileSize, or time directives, such as MaxFileSec.
On some systems that have persistent files, you can manually rotate (archive) active journals. If this feature is available on your system, you do this with the journalctl ‐‐rotate command.
On some distributions, the journal entries are stored in the /run/log/journal directory, which is volatile, meaning the directory is removed and the journal entries are lost whenever the system is shut down.
Here is an example of a journal file on a Red Hat–based distribution, where the journal is configured as volatile:
# ls /run/log/journal/0c00adfd05364b9d921be2a22c59e3ed/system.journal#
If desired, system admins can change a journal file from volatile to persistent. To accomplish this, set the Storage directive within the journald.conf file, changing it to persistent.
When this configuration is loaded (via a systemctl restart, which was covered earlier), systemd‐journald automatically creates the /var/log/journal directory, moves the journal file to its new location, and starts storing journal entries in it. Also, since this file is persistent, the file survives system shutdowns and reboots, and its entries are not removed.
While you can set the Storage directory to auto and create the /var/log/journal directory yourself, it's a little tricky getting the directory permissions set correctly. Thus, it's best to let systemd‐journald do the work for you.
The systemd‐journald program doesn't store journal entries in text files. Instead, it uses its own binary file format that works similar to a database. Although this makes it a little harder to view journal entries, it does provide for quick searching for specific event entries.
The journalctl program is our interface to the journal files. The basic format for the journalctl command is as follows:
journalctl [OPTIONS…] [MATCHES…]
The OPTIONS control how data returned by the MATCHES is displayed and/or additionally filtered. Table 15.2 lists commonly used switches.
TABLE 15.2: The journalctl Utility's Commonly Used Options
| SHORT OPTION | LONG OPTION | DESCRIPTION |
|---|---|---|
‐a |
‐‐all |
Display all data fields, including unprintable characters. |
‐e |
‐‐pager‐end |
Jump to the end of the journal and display the entries. |
‐g pattern
|
‐‐grep pattern
|
Display only entries that match pattern
. |
‐k |
‐‐dmesg |
Display only kernel entries. |
‐n number |
‐‐lines=number |
Show the most recent number of journal entries. |
‐r |
‐‐reverse |
Reverse the order of the journal entries in the output. |
‐S date
|
‐‐since= date |
Show journal entries starting at date
, where date is formatted as YYYY‐MM‐DD:HH:MM:SS. If a time specification is left off of date, then 00:00:00 is assumed. Keywords such as yesterday, today, tomorrow, and now can all replace date. |
‐U date
|
‐‐until= date |
Show journal entries until date is reached in the entries. date formatting is the same as it is for the ‐S option. |
‐u unit or pattern
|
‐‐unit= unit or pattern
|
Show only journal entries for the systemd unit or systemd units that match pattern
. |
By default, the journalctl utility employs the less pager to display its entries. To turn off this feature, use the ‐‐no‐pager option. Here is a simple snipped example of using journalctl without MATCHES and showing the last 20 messages without using the less pager on an Ubuntu system:
$ sudo journalctl ‐n 20 ‐‐no‐pager-- Logs begin […] end at Wed 2021-02-03 19:44:38Feb 03 19:08:32 […]sysadmin from […] port 63155 ssh2Feb 03 19:08:32 […]pam_unix(sshd:[…]user sysadmin by (uid=0)Feb 03 19:08:32 ubuntu-server […] of user sysadmin.Feb 03 19:08:32 ubuntu-server […] of user sysadmin.Feb 03 19:17:01 ubuntu-server […]root by (uid=0)Feb 03 19:17:01 […]CMD ( cd / && run-parts --report […]Feb 03 19:17:01 […]:session): session closed for user rootFeb 03 19:21:52 […]Cleanup of Temporary Directories…Feb 03 19:21:53 […]clean.service: Succeeded.Feb 03 19:21:53 […]Cleanup of Temporary Directories.Feb 03 19:31:34 […]Starting Message of the Day…Feb 03 19:31:35 […]Using degraded feature set[…]Feb 03 19:31:35 […]Using degraded feature set[…]Feb 03 19:31:43 ubuntu-server 50-motd-news[…]Feb 03 19:31:43 ubuntu-server 50-motd-news[…]Feb 03 19:31:43 ubuntu-server 50-motd-news[…]Feb 03 19:31:43 ubuntu-server systemd[1]: […].Feb 03 19:31:43 ubuntu-server systemd[1]: […]Feb 03 19:44:30 ubuntu-server sudo[1228]: […]Feb 03 19:44:32 ubuntu-server sudo[1228]: […]$
The MATCHES for the journalctl utility filter what type of journal entries to display. Table 15.3 lists the various commonly used filters that are available.
TABLE 15.3: The Common journalctl MATCHES Parameters Used for Filtering
| MATCH | DESCRIPTION |
|---|---|
field |
Match the specific field in the journal. You can enter multiple occurrences of field on the same line, but they must be separated with a space. You can separate multiple field specifications with a plus sign (+) to use a logical OR between them. |
OBJECT_PID=pid |
Match only entries made by the specified application pid
. |
PRIORITY=value |
Match only entries with the specified priority value. The value can be set to one of the following numbers or keywords: emerg (0), alert (1), crit (2), err (3), warning (4), notice (5), info (6), or debug (7). |
_HOSTNAME=host |
Match only entries from the specified host
. |
_SYSTEMD_UNIT=unit.type |
Match only entries made by the specified systemd unit
.
type
. |
_TRANSPORT=transport |
Match only entries received by the specified transport method. |
_UDEV_SYSNAME=dev |
Match only entries received from the specified device. |
_UID=userid |
Match only entries made by the specified user ID. |
To use journalctl to view all the various journal entries, you'll need to be logged in as the root user, use super user privileges, or typically belong to the systemd‐journal group. Recognize that your distribution may use a different group for this task.
When you are looking for specific event entries in the journal, use the desired filters and options to target specific items. In the following example, only today's entries for the ssh.service systemd service unit are displayed:
$ sudo journalctl ‐‐no‐pager ‐‐since=today _SYSTEMD_UNIT=ssh.service-- Logs begin at Wed 2020-10-14 17:34:10 UTC, end at Wed 2021-02-03 19:56[…]Feb 03 18:54:29 ubuntu-server sshd[696]: Server listening on 0.0.0.0 port 22.Feb 03 18:54:29 ubuntu-server sshd[696]: Server listening on :: port 22.Feb 03 19:05:58 ubuntu-server sshd[696]: Received signal 15; terminating.[…]Feb 03 19:06:54 ubuntu-server sshd[684]: Server listening on 0.0.0.0 port 22.Feb 03 19:06:54 ubuntu-server sshd[684]: Server listening on :: port 22.Feb 03 19:08:32 ubuntu-server sshd[1024]: Accepted password for sysadmin[…]Feb 03 19:08:32 ubuntu-server sshd[1024]: pam_unix(sshd:session): sessio[…]$
Employing various journalctl filters makes digging through journal files much easier.
The journalctl utility has a nice feature that allows you to watch the journal as entries are being added. Just employ the journalctl ‐f or ‐‐follow switch, and you will see the last few entries and additional entries as they are added to the journal. When you are done watching, press the Ctrl+C key combination to quit.
Besides configuring a persistent journal and keeping the journal disk usage in check, you have a few manual management activities you can employ for maintaining your journal file(s).
You can check the current disk usage of the persistent journal file(s) by employing the journalctl ‐‐disk‐usage command:
$ journalctl ‐‐disk‐usageArchived and active journals take up 104.0M in the file system.$
While systemd‐journald can automatically clean up disk space via settings in the journald.conf file, you can do so manually as well. In this case, you employ a vacuum … well, actually its vacuum options available on the journalctl command:
--vacuum-size--vacuum-time
As you would expect, ‐‐vacuum‐size removes journal files until the disk space consumed by journal files reaches the designated size. You follow the option with a number and tack on a unit (K, M, G, or T) to set the size. Be aware that this removes only archived journal files and has no effect on any active journal files.
For the ‐‐vacuum‐time option, you designate the oldest journal entries allowed, and the rest are deleted. The time is denoted with a number as well as a time unit (s, min, h, days, months, weeks, or years), such as 10months. Like the size option, the time option affects only archived journal files. The active files are left untouched.
While you can combine the two different switches if needed, this snipped example uses only the size option to pare down on disk usage:
$ journalctl ‐‐disk‐usageArchived and active journals take up 104.0M in the file system.$$ sudo journalctl ‐‐vacuum‐size=10M[…]Deleted archived journal /var/log/journal/97be[…](8.0M).Deleted archived journal /var/log/journal/97be[…] (8.0M).Deleted archived journal /var/log/journal/97be[…] (8.0M).Deleted archived journal /var/log/journal/97be[…] (8.0M).Deleted archived journal /var/log/journal/97be[…] (16.0M).Deleted archived journal /var/log/journal/97be[…](8.0M).Deleted archived journal /var/log/journal/97be[…] (16.0M).Vacuuming done, freed 72.0M of archived journa[…]$$ journalctl ‐‐disk‐usageArchived and active journals take up 32.0M in the file system.$
Notice that after the vacuuming was completed, another journalctl ‐‐disk‐usage command was issued, but it shows 32.0M instead of the 10M size set on the vacuum option. This is because though the disk‐usage switch shows both active and archived journal files, the vacuum options work only on archived journal files.
If you need to retrieve a journal file from a rescued system but view it first or look at the entries in an archived or copied journal file, a few journalctl switches are available that can help.
Because journalctl looks for the active journal files in either the /run/log/journal or /var/log/journal directory, you can point it to a different directory location where a copied or another system's journal file is located by using the ‐D directory‐name or ‐‐directory=
directory‐name option.
If the file you are trying to view has a different name than system.journal or user‐
UID
.journal, use the ‐‐file=
pattern option on the journalctl command. Set the pattern to be the exact name of the file you want to view. However, if there are several files, you can employ filename pattern‐matching within the pattern to match several files.
If you have recently rescued your system and now have two or more journal files with entries to view, you can merge them. To do this, use the ‐m or ‐‐merge switches on the journalctl utility. Keep in mind that this does not physically merge the journal files but instead merges their entries in the output for your perusal.
If you'd like to back up your active journal file(s), you can simply copy them. However, right before you make a copy, run the journalctl ‐‐sync command to ensure all the entries are moved from their queue into the file.
The systemd‐journald journal utility allows you to send your system's journals to a centralized journal host system via systemd‐journal‐remote. To view all the various journal files' entries on the central host, you'll need to employ the ‐m or ‐‐merge option when using the journalctl command.
If needed, you can add journal entries from the command line or scripts using the systemd‐cat tool. To do so, you must pipe your command's STDOUT into the utility:
COMMAND | systemd-cat
A quick test of employing the systemd‐cat command is easily checked using the ‐‐grep option on the journalctl command:
# echo "Hello World Test" | systemd‐cat## journalctl ‐‐no‐pager ‐‐grep "Hello World Test"[…]Feb 03 15:25:53 localhost.localdomain cat[1762]: Hello World Test#
This feature of adding your own journal entries is handy for adding additional tracking information, such as when installing new apps on a server or modifying configurations. It leaves a nice “trail of breadcrumbs” should you encounter problems due to these changes later.
In the early days of Unix, there were many different logging methods used to track system and application events. Applications used different logging methods, making it difficult for system administrators to troubleshoot issues.
With the development of an important core logging protocol, and many open source logging tools that rapidly evolved into utilities with familiar configuration‐file settings and interfaces, logging systems were now providing admins more useful troubleshooting information. The utilities and remnants of these advances still exist on many Linux distributions to this day.
In the mid‐1980s, Eric Allman defined a protocol for logging events from his Sendmail mail application, called syslog. The syslog protocol quickly became a standard for logging both system and application events in Unix and made its way to the Linux world.
What made the syslog protocol so popular is that it defines a standard message format that specifies the time stamp, type, severity, and details of an event. That standard can be used by the operating system, applications, and even devices that generate errors.
The type of event is defined as a facility value. The facility defines what is generating the event message, such as a system resource or an application. Table 15.4 lists the facility values defined in the syslog protocol.
TABLE 15.4: The syslog Protocol Facility Values
| CODE | KEYWORD | DESCRIPTION |
|---|---|---|
| 0 | kern |
Messages generated by the system kernel |
| 1 | user |
Messages generated by user events |
| 2 | mail |
Messages from a mail application |
| 3 | daemon |
Messages from system applications running in the background |
| 4 | auth |
Security or authentication messages |
| 5 | syslog |
Messages generated by the logging application itself |
| 6 | lpr |
Printer messages |
| 7 | news |
Messages from the news application |
| 8 | uucp |
Messages from the Unix‐to‐Unix copy program |
| 9 | cron |
Messages generated from the cron job scheduler |
| 10 | authpriv |
Security or authentication messages |
| 11 | ftp |
File Transfer Protocol application messages |
| 12 | ntp |
Network Time Protocol application messages |
| 13 | security |
Log audit messages |
| 14 | console |
Log alert messages |
| 15 | solaris
‐
cron |
Another scheduling daemon message type |
| 16–23 | local0
–
local7 |
Locally defined messages |
As you can tell from Table 15.4, the syslog protocol covers many different types of events that can appear on a Linux system.
Each event is also marked with a severity. The severity value defines how important the message is to the health of the system. Table 15.5 shows the severity values as defined in the syslog protocol.
TABLE 15.5: The syslog Protocol Severity Values
| CODE | KEYWORD | DESCRIPTION |
|---|---|---|
| 0 | emerg |
An event causes the system to be unusable. |
| 1 | alert |
An event that requires immediate attention. |
| 2 | crit |
An event that is critical, but doesn't require immediate attention. |
| 3 | err |
An error condition that allows the system or application to continue. |
| 4 | warning |
A non‐normal warning condition in the system or application. |
| 5 | notice |
A normal but significant condition message. |
| 6 | info |
An informational message from the system. |
| 7 | debug |
Debugging messages for developers. |
Combining the facility and severity codes with a short informational message provides enough logging information to troubleshoot almost any problem in Linux.
Over the years, there have been many open source logging projects for Linux systems. One that uses the syslog protocol is the rsyslog project, whose developers' claim that the r stands for “rocket fast.” Speed is the focus of the rsyslog project, and the rsyslog application quickly became a standard logging package for many Linux distributions.
The rsyslog application uses the rsyslogd program to monitor events and log them as directed, using the /etc/rsyslogd.conf configuration file to define what events to listen for, and how to handle them. Many Linux distributions also use a /etc/rsyslog.d/ directory to store individual configuration files that are included as part of the rsyslog.conf configuration. This allows applications to define their own log settings.
The configuration file contains rules that define how the program handles syslog events received from the system, kernel, or applications. The format of an rsyslogd rule is as follows:
facility.priority action
The facility entry uses one of the standard syslog protocol facility keywords. The priority entry uses the severity keyword as defined in the syslog protocol, but with a twist. When you define a severity, rsyslogd will log all events with that severity or higher. Thus, the following entry logs all kernel event messages with a severity of critical, alert, or emergency:
kern.crit
To log only messages with a specific severity, use an equal sign before the priority keyword:
kern.=crit
You can also use wildcard characters for either the facility or priority. The entry logs all events with an emergency severity level:
*.emerg
The action entry defines what rsyslogd should do with the received syslog protocol message. There are six action options you have available:
Some of the entries for directing log messages in the /etc/rsyslogd.conf file on a CentOS system are shown here:
$ cat /etc/rsyslog.conf# rsyslog configuration file[…]# Include all config files in /etc/rsyslog.d/include(file="/etc/rsyslog.d/*.conf" mode="optional")#### RULES ##### Log all kernel messages to the console.# Logging much else clutters up the screen.#kern.* /dev/console[…]# The authpriv file has restricted access.authpriv.* /var/log/secure# Log all the mail messages in one place.mail.* -/var/log/maillog# Log cron stuffcron.* /var/log/cron# Everybody gets emergency messages*.emerg :omusrmsg:*# Save news errors of level crit and higher in a special file.uucp,news.crit /var/log/spooler# Save boot messages also to boot.loglocal7.* /var/log/boot.log[…]$
Notice the dash in front of the /var/log/maillog filename. This lets rsyslogd know that there is no need to update the log file (sync) after every single mail event. Typically, this configuration speeds logging up a little, but on certain filesystems, it runs the risk of losing some events.
If desired (or required), you can have both systemd‐journald and a syslog protocol application, such as rsyslog, running and working together. There are two primary ways to accomplish this:
For rsyslog, if this method is not already configured or you'd like to check your system, look in the /etc/rsyslog.conf file. It needs to have the imuxsock and/or imjournal module being loaded via module without a preceding pound sign (#), as shown snipped here:
$ cat /etc/rsyslog.confmodule(load="imuxsock" #[…] local system logging[…]module(load="imjournal" #[…] access to the systemd journal$
/run/systemd/journal/syslog. Messages are forwarded to the file (called a socket) where a syslog protocol program can read them.
To use this method, you need to modify the journal configuration file, /etc/systemd/journald.conf, and set the ForwardToSyslog directive to yes. Keep in mind that you'll need to load the modified journald.conf file into systemd‐journald for it to take effect. Unfortunately, you cannot employ the systemctl reload option to load the new configuration for systemd‐journald. Instead, using super user privileges, you must restart the service using the systemctl restart systemd‐journald command.
If you create and run scripts on your Linux system (Bash shell scripts are covered in Chapter 19, “Writing Scripts”), you may want to log your own application events using rsyslog. You can do that with the logger command‐line tool:
logger [-isd] [-f file] [-p priority] [-t tag] [-u socket] [message]
The ‐i option specifies the process ID (PID) of the program that created the log entry as part of the event message. The ‐p option allows you to specify the event priority. The ‐t option allows you to specify a tag to add to the event message to help make finding the message in the log file easier. Either you can specify the message as text in the command line or you can specify it as a file using the ‐f option. The ‐d and ‐u options are advanced options for sending the event message to the network. The ‐s option sends the event message to the standard error output.
An example of using logger looks like this:
$ logger This is a test message from script123.sh$
On an Ubuntu system, you can look at the end of the /var/log/syslog file to see the manually created log entry:
$ tail ‐n 2 /var/log/syslogFeb 10 18:07:32 ubuntu-server systemd[1]:Started Session 3 of user sysadmin.Feb 10 18:08:09 ubuntu-server sysadmin:This is a test message from script123.sh$
Notice that rsyslogd added the time stamp, hostname, and user account for the message. This provides a lot of information for use in troubleshooting!
Generally, most Linux distributions create log files in the /var/log directory. Depending on the security of the Linux system, many log files are readable by everyone, but some may not be.
Most Linux distributions create separate log files for different event message types. However, they don't always agree on the log filenames.
It's also common for individual applications to have a separate directory under the /var/log directory for their own application event messages, such as /var/log/apache2 for the Apache web server.
The easiest way to find the rsyslog log files for your system is to examine the /etc/rsyslogd.conf configuration file. Just remember to also look at the files stored in the /etc/rsyslog.d directory.
As you can guess, for busy Linux systems, it doesn't take long to generate large log files. To help combat that, many Linux distributions install the logrotate utility. It automatically splits rsyslogd log files into archive files based on a time or the size of the file. You can usually identify archived log files by the numerical extension added to the log filename, so if the event information you are searching for is older, you may need to go perusing through those log files.
Since rsyslogd log files are text files, you can use any of the standard text tools available in Linux, such as cat, head, tail, and less, to view them. One common trick for administrators is to use the ‐f option with the tail command. That displays the last few lines in the log file, but then monitors the file for any new entries and displays those too.
journalctl program is needed to view journal file entries, because unlike some logging utilities, systemd‐journald doesn't store events in text files. Instead, it uses its own binary file format that works similar to a database. Thus, you cannot use the typical programs used to view text files, such as cat, head, or tail, to view journal file entries.
journalctl command(s) to use in this scenario?systemd‐journald journal file(s) can get rather large. Because the various services on the system are sending messages to this file, if multiple events are occurring on a regular basis, disk space can quickly become consumed. It's important to make some decisions on journal file size limits prior to lack of disk space becoming a critical emergency issue.
systemd‐journald journal files. After running the journalctl ‐‐disk‐usage program, you've made some decisions on journal file size limits and determine a rotation schedule, which includes an archival process for the old files. Which directives should you consider modifying in the /etc/systemd/journald.conf file to match your decisions concerning this and prevent a critical emergency issue with disk space due to journal files?/run/log/journal directory. The /run/ directory and its contents are deleted when a system is shut down, so any journal entries are lost at that time. It is typical to change this behavior by modifying a directive in the /etc/systemd/journald.conf file to force systemd‐journald to keep entries in a journal that is not removed when the system is shut down or reboots. The /var/log/journal directory is used in these cases to store the journal file(s).
systemd‐journald configuration file. What directive should you change in the configuration files on these servers, and what should you set it to?/etc/rsyslogd.conf, or a combination of that configuration file and additional configuration files within the /etc/rsyslog.d/ directory. Modifying the rsyslog application's configuration is fairly straightforward with the facility
.
priority action syntax in its configuration rules.
rsyslogd program to send the following severity level of events for all systems to everyone: crit, alert, and emerg. What do you need to do?