Red Hat Certified System Administrator (RHCSA) #9 System Operations: chronyd, journald, cron, systemd timer, tuned

9 min read

Where #8 Packages and repositories covered installing and managing software with dnf, this post covers the everyday tasks that keep a running system healthy. Setting time, reading logs, scheduling jobs, and picking a performance profile are areas where RHCSA points are easy to drop. The commands are simple, so drilling them lets you handle each task quickly on the exam.

These four tasks (time, logs, scheduling, tuning) only score points if they survive a reboot. A cron job has to stay registered, journald persistence has to be configured, and NTP synchronization has to kick in automatically after boot. So this post checks persistence alongside each task.

Managing system time #

A system with the wrong time immediately runs into trouble with log timestamps, certificate validation, and cluster synchronization. The entry point for time management on RHEL 9 is timedatectl, while the actual time synchronization is handled over NTP by the chronyd service.

Checking and setting state with timedatectl #

Let’s see the current time, time zone, and sync state at a glance.

# Check current state
timedatectl

# Example output
#                Local time: Sat 2026-06-06 14:30:00 KST
#            Universal time: Sat 2026-06-06 05:30:00 UTC
#                  Time zone: Asia/Seoul (KST, +0900)
# System clock synchronized: yes
#               NTP service: active

System clock synchronized: yes and NTP service: active tell you synchronization is healthy.

Set the time zone as follows.

# Search the list of available time zones
timedatectl list-timezones | grep -i seoul

# Set the time zone
timedatectl set-timezone Asia/Seoul

# Turn on NTP synchronization
timedatectl set-ntp true

You can’t set the time manually while NTP is active, so if you need to set it by hand, first disable synchronization with timedatectl set-ntp false and then specify the time with timedatectl set-time "2026-06-06 14:00:00". On the exam, enabling NTP synchronization is usually the right answer.

chronyd and /etc/chrony.conf #

The actual NTP synchronization is handled by chronyd, with its configuration in /etc/chrony.conf. A task that shows up often on the exam is editing the configuration file to point at a specified NTP server.

# Install the package if it's missing
dnf install -y chrony

# Edit the configuration file
vi /etc/chrony.conf

The key directives in /etc/chrony.conf are as follows.

# Specify the NTP server (replace with the server given on the exam)
server classroom.example.com iburst

# You can also pull a pool of multiple servers
pool 2.rhel.pool.ntp.org iburst

# The range allowed to receive time from this host on the local network
# allow 192.168.0.0/16

The iburst option sends a burst of requests immediately after the service starts, so synchronization happens quickly. Adding it when you add a server on the exam speeds up your sync check.

After changing the configuration, restart the service and ensure it starts automatically at boot.

systemctl restart chronyd
systemctl enable chronyd

Verifying NTP synchronization #

To confirm the configuration actually took effect, check with chronyc.

# List of sources currently being synced
chronyc sources

# Example output (^* is the server currently being synced)
# MS Name/IP address         Stratum Poll Reach LastRx Last sample
# ===============================================================
# ^* classroom.example.com         3   6    17    23   +12us[...]

# Sync tracking state (offset, accuracy)
chronyc tracking

In the chronyc sources output, the ^* mark in front of a server means it’s the source currently being synced. When the server you added to the configuration file appears in this list and timedatectl shows synchronized: yes, the task is complete.

Log management: journald and rsyslog #

On RHEL 9, logs are collected by systemd’s journald into a binary journal and queried with journalctl. When you need text logs, rsyslog also writes them to traditional files under /var/log/.

Reading logs with journalctl #

The options for journalctl are often asked verbatim on the exam, so let’s organize the forms you use most.

# Logs from a specific unit (service) only
journalctl -u sshd

# Filter by priority (err and above only)
journalctl -p err

# Filter by time range
journalctl --since "2026-06-06 09:00:00"
journalctl --since "1 hour ago"
journalctl --since yesterday --until "2026-06-06 12:00:00"

# This boot's logs only
journalctl -b

# The previous boot's logs (-1)
journalctl -b -1

# Follow in real time
journalctl -f

-p (priority) takes the priorities in the order emerg, alert, crit, err, warning, notice, info, debug, and shows the specified level and above. The options combine freely, so practicing narrowing down in one go like journalctl -u sshd -p err --since today helps.

journald persistent storage (Storage=persistent) #

By default, journald stores logs in memory under /run/log/journal, so they disappear on reboot. A staple RHCSA task is changing this so logs persist to disk.

# Edit the configuration file
vi /etc/systemd/journald.conf

In the [Journal] section, set Storage as follows.

[Journal]
Storage=persistent

Persistent storage is written to the /var/log/journal directory. Creating the directory ahead of time, fixing its permissions, and then restarting the service makes it certain.

# Create the persistent storage directory
mkdir -p /var/log/journal

# Apply ownership and permissions (a systemd-provided tool)
systemd-tmpfiles --create --prefix /var/log/journal

# Restart journald to apply the configuration
systemctl restart systemd-journald

With this in place you can query all the way back to the previous boot’s logs with journalctl -b -1, which lets you confirm directly that the configuration took effect.

rsyslog in one line #

You can see every log with journalctl, but RHEL still leaves text logs like /var/log/messages and /var/log/secure via rsyslog. Its configuration lives in /etc/rsyslog.conf and /etc/rsyslog.d/, and it’s enough to remember that authentication logs are in /var/log/secure and general system messages in /var/log/messages.

Scheduling jobs: cron and systemd timer #

There are two ways to run a job on a schedule: the traditional cron and systemd’s timer. RHCSA mostly tests cron, but knowing systemd timer as well is the safe bet.

User crontab #

Per-user scheduled jobs are managed with the crontab command.

# Edit the current user's crontab
crontab -e

# List the current user's crontab
crontab -l

# Edit a specific user's crontab (root only)
crontab -u alice -e

# Remove the current user's crontab
crontab -r

A crontab line has five fields in the format minute hour day month weekday command.

# ┌───── minute (0-59)
# │ ┌───── hour (0-23)
# │ │ ┌───── day (1-31)
# │ │ │ ┌───── month (1-12)
# │ │ │ │ ┌───── weekday (0-7, 0 and 7 are Sunday)
# │ │ │ │ │
# * * * * * command to run

# Run daily at 14:23
23 14 * * * /usr/local/bin/backup.sh

# Every Monday at 3:00 AM sharp
0 3 * * 1 /usr/local/bin/weekly.sh

# Every 5 minutes
*/5 * * * * /usr/local/bin/check.sh

On the exam this typically appears as “have a specific user run a command at a given hour and minute every day,” so it’s important to target the right user precisely with crontab -u user -e.

/etc/cron.d and system cron #

System-level scheduling lives in /etc/crontab or in files under /etc/cron.d/. Unlike a user crontab, this format adds the user to run as right after the time fields.

# /etc/cron.d/mytask
# minute hour day month weekday  user  command
30 2 * * *  root  /usr/local/bin/system-backup.sh

Besides this, placing an executable script in a directory like /etc/cron.daily/ or /etc/cron.hourly/ runs it automatically at that interval.

systemd timer (.timer / .service) #

A systemd timer works as a pair of units: the .service that defines what to run, and the .timer that defines when to run it.

First, define the job to run as a .service.

# /etc/systemd/system/backup.service
[Unit]
Description=Daily backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Next, define the run time as a .timer.

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

OnCalendar is the key directive for expressing the time. You can use shorthands like daily and weekly, or combine weekday and time like Mon *-*-* 03:00:00. Persistent=true makes a run that was missed because the system was off catch up after boot.

For the timer, you enable the .timer unit.

# Reload units, then activate the timer
systemctl daemon-reload
systemctl enable --now backup.timer

# Check registered timers and their next run time
systemctl list-timers

You can verify that an OnCalendar expression is interpreted as intended with the following.

# Validate the OnCalendar expression and print the next run time
systemd-analyze calendar "*-*-* 02:30:00"

Tuning system profiles with tuned #

tuned is a service that applies a bundle of kernel, disk, and network parameters matched to the nature of a workload. On RHCSA it shows up as a task to activate a specified profile.

# Activate the tuned service (if needed)
systemctl enable --now tuned

# List of available profiles and the currently recommended profile
tuned-adm list

# Check the currently active profile
tuned-adm active

# Apply a profile
tuned-adm profile throughput-performance

# Auto-select the profile recommended for the system
tuned-adm recommend

Representative profiles include balanced (general purpose), throughput-performance (throughput-oriented), virtual-guest (for virtual machine guests), and latency-performance (minimizing latency). On the exam you simply apply the given profile name with tuned-adm profile and confirm with tuned-adm active.

Exam points #

  • Time synchronization. Set the time zone with timedatectl set-timezone and turn on NTP with timedatectl set-ntp true. To specify an NTP server, edit the server/pool line in /etc/chrony.conf, apply it with systemctl restart chronyd, and confirm the sync via the ^* in chronyc sources.
  • journald persistence. Put Storage=persistent in /etc/systemd/journald.conf, create /var/log/journal, then apply it with systemctl restart systemd-journald. If journalctl -b -1 shows the previous boot’s logs, you’ve succeeded.
  • Reading logs. Practice narrowing down by combining journalctl’s -u, -p, --since/--until, and -b.
  • cron jobs. Register your own jobs with crontab -e, and a target user’s jobs with crontab -u user -e. Get the minute hour day month weekday field order exactly right.
  • systemd timer. Make a .service and .timer as a pair, specify the time with OnCalendar, then enable the .timer. Confirm the next run with systemctl list-timers.
  • tuned. Apply with tuned-adm profile name and confirm with tuned-adm active.
  • Persistence. chronyd and tuned via systemctl enable, cron jobs persist by virtue of being registered, and a timer has to stay alive after boot via enable --now to score.

Wrap-up #

What this post locked in:

  • Time. Control the time zone and NTP with timedatectl, specify the NTP server in /etc/chrony.conf, and confirm synchronization with chronyc sources / chronyc tracking.
  • Logs. Read logs with journalctl’s filter options, and persist the journal to disk with Storage=persistent. Text logs are left by rsyslog in /var/log/.
  • Scheduling. Configure cron jobs with crontab and /etc/cron.d, and systemd timers with .timer/.service and OnCalendar.
  • Tuning. Apply and confirm a system performance profile with tuned-adm.
  • Traps. journald is volatile by default, so skipping the persistence setting means logs are gone after a reboot. Getting cron’s field order wrong or omitting the user field in cron.d are also common point-losers.

Next — Basic networking #

We’ve locked in the time, logs, scheduling, and tuning of system operations. Now we move on to getting the system onto the network.

In #10 Basic networking: NetworkManager (nmcli), hostname, /etc/hosts, we’ll type our way through making a connection with nmcli and setting IP, gateway, and DNS persistently, changing the hostname with hostnamectl, and resolving names with /etc/hosts.

X