Rocky Linux’s dnf‑automatic: Keep Your Systems Secure with a Hand‑Off Scheduler
Keep Rocky Linux systems secure with dnf‑automatic: a scheduled updater that installs security patches and handles reboots. Learn how to enable, tune, and verify the service, and understand the trade‑offs for production use.
31 Jan 2026, 13:23 UTC

Problem: The Human Cost of Manual Patching
In a production environment, forgetting to apply a critical security update can leave a system exposed for days, if not weeks. Patch cycles are often scheduled during maintenance windows, but the manual steps—checking for updates, testing, installing, rebooting—introduce room for error. Even a single missed update can violate compliance mandates and increase the attack surface.
The Solution: dnf‑automatic in Rocky Linux
What It Is and How It Works
Rocky Linux ships a ready‑to‑use service called dnf-automatic that runs as a systemd timer. The timer fires daily (by default) and performs three tasks: 1) checks the configured mirrors for available packages, 2) installs any security updates that are not blocked by user configuration, and 3) optionally reboots the host if a reboot is required. Because it is integrated into dnf, the service respects the same repository metadata and package signing checks that you use for manual installs.
Tuning the Service for Your Environment
The behaviour of dnf-automatic is driven by /etc/dnf/automatic.conf. Key options include:
| Option | Default | Description |
|---|---|---|
| apply_updates | True | Whether to install updates automatically. |
| reboot_policy | when_required | When to reboot: no, always, or when_required. |
| random_sleep | 0 | Random delay (seconds) to spread update traffic. |
Logs are written to /var/log/dnf-automatic.log and can be streamed with journalctl -u dnf-automatic.service for audit purposes.
Hands‑On Example
Enable, Configure, and Verify
Run the following as root (or with sudo):
# Enable the timer and start it immediately
systemctl enable --now dnf-automatic.timer
# Confirm the timer is active
systemctl status dnf-automatic.timer
# Edit the configuration file
vim /etc/dnf/automatic.conf
# Set desired options, e.g.:
# apply_updates=True
# reboot_policy=no
# Restart the timer so changes take effect
systemctl restart dnf-automatic.timer
Check the service status again to ensure the new configuration is in place. If the timer shows a last run time in the past and a next trigger in the future, it is functioning correctly.
Trigger a Manual Update
To exercise the service without waiting for the scheduled timer, use the command‑line interface:
# Apply pending updates immediately
dnf-automatic --apply
After the run, inspect the log:
# View the last few lines of the update log
tail -n 20 /var/log/dnf-automatic.log
The log will show the packages processed, any errors, and whether a reboot was requested.
Trade‑offs & Caveats
Reboot Policy and Critical Services
Automatic reboots can interrupt time‑sensitive workloads. If your system hosts a database or a real‑time application, set reboot_policy=no and schedule reboots manually during maintenance windows. Alternatively, use when_required to let the service reboot only when a kernel update demands it.
Custom Configurations and Compatibility
Updating packages that modify configuration files may overwrite custom settings. It is prudent to test the automated cycle in a staging environment before deploying to production. The service respects the exclude directives in /etc/dnf/dnf.conf, so you can shield critical packages from automatic updates if needed.
Network Reliability
On hosts with intermittent connectivity, failed update attempts will be retried on the next timer tick. This can lead to repeated bandwidth consumption during off‑peak hours. Consider adding random_sleep or adjusting the timer schedule to mitigate this.
Takeaway
Enabling dnf-automatic on Rocky Linux reduces the administrative burden of patch management while maintaining auditability through logs and systemd monitoring. By tuning apply_updates and reboot_policy to match your operational constraints, you can achieve a balance between security and uptime.
Next steps for a production setup: 1) enable the timer, 2) adjust the configuration to avoid unintended reboots, 3) monitor logs for the first few cycles, and 4) document the process in your change‑management workflow.