Learning AlmaLinux - Logging, Time Sync & Basic Automation

#Introduction

In the previous episode, Episode 11, we observed the system with Cockpit and monitoring commands. Now we organize three operational foundations that are often underestimated even though they determine success in the field: logging (the system's trail), time sync (time accuracy), and automation (repetitive work without humans).

A server with messy logs, a drifting clock, and manual tasks is an operations nightmare. This episode tidies up all three.

#Logging: journald and rsyslog

In episode 7 we got to know journald as systemd's main logger. However, AlmaLinux also runs rsyslog — the traditional logging daemon that writes logs to text files in /var/log/. The two coexist: journald stores structured logs, rsyslog writes to classic files.

#The /var/log Hierarchy

sudo tail -n 20 /var/log/secure

#Forwarding Journal to Files

For specific services, you can redirect logs from journald to text files — useful when integrating with systems that only read files:

:programname, isequal, "myapp" /var/log/myapp.log
& stop

This line tells rsyslog to write all messages from the myapp program to a dedicated file, then stop processing. After adding the file, restart rsyslog.

#Logrotate

Logs grow out of control if left unchecked. logrotate automates rotation: moving old logs, compressing them, and keeping a set number.

/var/log/myapp.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

This pattern rotates the log daily, keeps the last 7 files, and compresses them. The default configuration is in /etc/logrotate.conf, and per-service files go in /etc/logrotate.d/. Test rotation without waiting for the schedule:

sudo logrotate -d /etc/logrotate.d/myapp

#Time Sync: chrony

Accurate time is an absolute requirement of modern servers: cross-host logs can be compared, TLS certificates stay valid, and database replication runs correctly. AlmaLinux uses chrony as its NTP client.

timedatectl
chronyc tracking

#chrony Configuration

Time servers are configured in /etc/chrony.conf:

pool 2.pool.ntp.org iburst
makestep 1 3
rtcsync

pool ... iburst pulls time from several servers at once, makestep allows time jumps at startup, and rtcsync syncs the hardware clock. Restart after changing:

sudo systemctl restart chronyd
chronyc sources

#Automation: Cron, Anacron, and Systemd Timers

Routine tasks like backups and log rotation shouldn't depend on humans. Three scheduling mechanisms are available on AlmaLinux.

#Cron and Crontab

cron is the classic scheduler. Every user has a crontab:

crontab -e

The cron format has five columns: minute hour day-of-month month day-of-week command:

0 2 * * * /usr/local/bin/backup.sh
30 1 * * 0 dnf5 autoremove

#Anacron

Cron doesn't run tasks missed while the system was off. anacron closes this gap — it makes sure scheduled tasks still run after the system comes back up, even if late. On AlmaLinux, cron and anacron run together to handle daily/weekly tasks.

#Systemd Timers

Systemd provides modern scheduling via timer units — with advantages: integration with service units, unified logging in journald, and the ability to catch up on missed tasks.

[Unit]
Description=Daily backup
 
[Timer]
OnCalendar=daily
Persistent=true
 
[Install]
WantedBy=timers.target

OnCalendar=daily runs it every day; Persistent=true runs tasks missed while the system was off. Pair it with a backup.service unit and enable:

sudo systemctl enable --now backup.timer
systemctl list-timers

#Boot Optimization with systemd-analyze

Finally, a rarely explored diagnostic command: systemd-analyze. It measures boot time and finds services that slow down startup.

systemd-analyze
systemd-analyze blame

systemd-analyze shows the total boot time; blame sorts services by initialization time. Services taking a disproportionate amount of time are candidates for optimization — for example, delaying non-critical services so they don't compete at boot.

#Common Pitfalls

1. Disabling rsyslog. journald alone is enough in many cases, but file log integration and forwarding often need rsyslog. Don't disable it without reason.
2. Forgetting logrotate for custom logs. Logs without rotation will fill the disk — always create a file in /etc/logrotate.d/.
3. Ignoring time synchronization. Logs with drifting timestamps make forensics and auditing useless. Check chronyc tracking regularly.
4. Using cron for tasks that can be missed. Consider Persistent=true in systemd timers or anacron for tasks that must still run.
5. Writing cron commands without logging. Always redirect output (>> /var/log/task.log 2>&1) so errors are recorded.

#Conclusion

In this episode 12 you've organized AlmaLinux's operational foundations: the journald and rsyslog log flow with the /var/log/ hierarchy and logrotate, accurate time synchronization with chrony, automatic scheduling via cron, anacron, and systemd timers, and boot speed analysis with systemd-analyze.

Key takeaways:

• journald stores structured logs; rsyslog writes classic files in /var/log/ like secure and messages.
• logrotate limits log growth — per-service configuration in /etc/logrotate.d/.
• chrony keeps time accurate; check with chronyc tracking and chronyc sources.
• Automate with cron (classic) or systemd timers (modern, log-integrated).
• systemd-analyze blame finds services that slow down boot.

A tidy operational foundation makes you ready to step into the security domain. In the next episode, Episode 13, we'll cover SELinux & Mandatory Access Control — the difference between MAC and DAC, enforcing, permissive, and disabled modes, reading and fixing contexts, booleans, and troubleshooting blocked services. See you there!