RH134 - ch03s07

By default, Red Hat Enterprise Linux 9 stores the system journal in the /run/log directory, and the system clears the system journal after a reboot. You can change the configuration settings of the systemd-journald service in the /etc/systemd/journald.conf file so that the journals persist across a reboot.

The Storage parameter in the /etc/systemd/journald.conf file defines whether to store system journals in a volatile manner or persistently across a reboot. Set this parameter to persistent, volatile, auto, or none, as follows:

persistent: Stores journals in the /var/log/journal directory, which persists across reboots. If the /var/log/journal directory does not exist, then the systemd-journald service creates it.
volatile: Stores journals in the volatile /run/log/journal directory. Because the /run file system is temporary and exists only in the runtime memory, the data in it, including system journals, does not persist across a reboot.
auto: If the /var/log/journal directory exists, then the systemd-journald service uses persistent storage; otherwise it uses volatile storage. This action is the default if you do not set the Storage parameter.
none: Do not use any storage. The system drops all logs, but you can still forward the logs.

The advantage of persistent system journals is that the historical data is available immediately at boot. However, even with a persistent journal, the system does not keep all data forever. The journal has a built-in log rotation mechanism that triggers monthly. In addition, the system does not allow the journals to get larger than 10% of the file system that they are on, or leaving less than 15% of the file system free. You can modify these values for both the runtime and persistent journals in the /etc/systemd/journald.conf configuration file.

The systemd-journald process logs the current limits on the size of the journal when it starts. The following command output shows the journal entries that reflect the current size limits:

[user@host ~]$ journalctl | grep -E 'Runtime Journal|System Journal'
Mar 15 04:21:14 localhost systemd-journald[226]: Runtime Journal (/run/log/journal/4ec03abd2f7b40118b1b357f479b3112) is 8.0M, max 113.3M, 105.3M free.
Mar 15 04:21:19 host.lab.example.com systemd-journald[719]: Runtime Journal (/run/log/journal/4ec03abd2f7b40118b1b357f479b3112) is 8.0M, max 113.3M, 105.3M free.
Mar 15 04:21:19 host.lab.example.com systemd-journald[719]: System Journal (/run/log/journal/4ec03abd2f7b40118b1b357f479b3112) is 8.0M, max 4.0G, 4.0G free.

Note

In the previous grep command, the vertical bar (|) symbol acts as an or operator. That is, the grep command matches any line with either the Runtime Journal string or the System Journal string from the journalctl command output. This command fetches the current size limits on the volatile (Runtime) journal store and on the persistent (System) journal store.

Configure Persistent System Journals

Configure the systemd-journald service as follows to preserve system journals persistently across a reboot:

Create the /var/log/journal directory.

[root@host ~]# mkdir /var/log/journal

Set the Storage parameter to the persistent value in the /etc/systemd/journald.conf file. Run your chosen text editor as the superuser to edit the /etc/systemd/journald.conf file.

[Journal]
Storage=persistent
...output omitted...

Restart the systemd-journald service to apply the configuration changes.

[root@host ~]# systemctl restart systemd-journald

If the systemd-journald service successfully restarts, then the service creates subdirectories in the /var/log/journal directory. The subdirectory in the /var/log/journal directory has hexadecimal characters in its long name and contain files with the .journal extension. The .journal binary files store the structured and indexed journal entries.

[root@host ~]# ls /var/log/journal
4ec03abd2f7b40118b1b357f479b3112
[root@host ~]# ls /var/log/journal/4ec03abd2f7b40118b1b357f479b3112
system.journal  user-1000.journal

Although the system journals persist after a reboot, the journalctl command output includes entries from the current system boot as well as from the previous system boots. To limit the output to a specific system boot, use the journalctl command -b option. The following journalctl command retrieves the entries from the first system boot only:

[root@host ~]# journalctl -b 1
...output omitted...

The following journalctl command retrieves the entries from the second system boot only. The argument is meaningful only if the system was rebooted at least twice:

[root@host ~]# journalctl -b 2
...output omitted...

You can list the system boot events that the journalctl command recognizes, by using the --list-boots option.

[root@host ~]# journalctl --list-boots
  -6 27de... Wed 2022-04-13 20:04:32 EDT—Wed 2022-04-13 21:09:36 EDT
  -5 6a18... Tue 2022-04-26 08:32:22 EDT—Thu 2022-04-28 16:02:33 EDT
  -4 e2d7... Thu 2022-04-28 16:02:46 EDT—Fri 2022-05-06 20:59:29 EDT
  -3 45c3... Sat 2022-05-07 11:19:47 EDT—Sat 2022-05-07 11:53:32 EDT
  -2 dfae... Sat 2022-05-07 13:11:13 EDT—Sat 2022-05-07 13:27:26 EDT
  -1 e754... Sat 2022-05-07 13:58:08 EDT—Sat 2022-05-07 14:10:53 EDT
   0 ee2c... Mon 2022-05-09 09:56:45 EDT—Mon 2022-05-09 12:57:21 EDT

The following journalctl command retrieves the entries from the current system boot only:

[root@host ~]# journalctl -b
...output omitted...

Note

When debugging a system crash with a persistent journal, usually you must limit the journal query to the reboot before the crash happened. You can use the journalctl command -b option with a negative number to indicate how many earlier system boots to include in the output. For example, the journalctl -b -1 command limits the output to only the previous boot.

References

systemd-journald.conf(5), systemd-journald(8) man pages

For more information, refer to the Troubleshooting Problems Using Log Files section in the Red Hat Enterprise Linux 9 Configuring Basic System Settings guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/configuring_basic_system_settings/index#troubleshooting-problems-using-log-files_getting-started-with-system-administration

Discuss Red Hat System Administration II

Go to community

Is It possible to reset root password when the system is on multi-user.target?

jennifer1987

27 lip 2023

Hi thereWell, i have a question, Is It possible to reset root password when the system is on multi-user.target? I was not be able to found a foro o some information related with this and another question that I have, If the grub menu dont show up, is it posible to reset the root password?

991

Red Hat System Administration II (RH134)

Haley_Ruccio

21 lip 2023

Build the skills to perform the key tasks needed to become a full-time Linux administratorRed Hat System Administration II (RH134) is the second part of the RHCSA training track for IT professionals who have already attended Red Hat System Administration I. The course goes deeper into core Linux system administration skills in storage configuration and management, installation and deployment of Red Hat Enterprise Linux, management of security features such as SELinux, control of recurring system tasks, management of the boot process and troubleshooting, basic system tuning, and command-line automation and productivity. This course assumes that students have attended Red Hat System Administration I (RH124).Experienced Linux administrators who seek rapid preparation for the RHCSA certification should instead start with RHCSA Rapid Track (RH199).This course is based on Red Hat Enterprise Linux 9.0.Course summaryInstall Red Hat Enterprise Linux using scalable methodsAccess security files, file systems, and networksExecute shell scripting and automation techniquesManage storage devices, logical volumes, and file systemsManage security and system accessControl the boot process and system servicesRun containersAudience for this courseThis course is geared toward Windows system administrators, network administrators, and other system administrators who are interested in supplementing current skills or backstopping other team members, in addition to Linux system administrators who are responsible for these tasks:Configuring, installing, upgrading, and maintaining Linux systems using established standards and proceduresProviding operational supportManaging systems for monitoring system performance and availabilityWriting and deploying scripts for task automation and system administrationRecommended trainingSuccessful completion of Red Hat System Administration I (RH124) is recommended.Experienced Linux administrators seeking to accelerate their path toward becoming a Red Hat Certified System Administrator should start with the RHCSA Rapid Track course (RH199).Take our free assessment to gauge whether this offering is the best fit for your skills.Technology considerationsThere are no special technology requirements.This course is not designed for bring your own device (BYOD).Internet access is not required, but is recommended to allow students to research and access Red Hat online resources.

Welcome to the Red Hat System Administration II (RH134) group in the Red Hat Learning Community!

Deanna

18 lip 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat System Administration II! To gain the most value from this group - click the "Join Group" button in the upper right hand corner.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH134.Read more about Red Hat System Administration II here.

417

Revision: rh134-9.3-5fd2368

Click CREATE to build all of the virtual machines needed for the classroom lab environment. This may take several minutes to complete. Once created the environment can then be stopped and restarted to pause your experience.

If you DELETE your lab, you will remove all of the virtual machines in your classroom and lose all of your progress.