You left your workstation running overnight
A critical security advisory drops at 3 AM. By the time you sit down at your desk, your system is still running the vulnerable kernel from last Tuesday. Manual updates work when you remember to run them. They fail when you are traveling, when your laptop sleeps, or when a CVE requires immediate patching. Automatic updates remove the human variable from the equation. They also introduce a new variable: trust. You need to know exactly what the system will do before you hand it the keys.
What is actually happening
Fedora does not ship with a background daemon that silently reboots your machine and replaces your desktop environment. The automatic update system relies on dnf-automatic, a package that wraps the standard package manager in a scheduled task. It uses systemd timers to wake up, check the repositories, and act on the results. The behavior is entirely controlled by a single configuration file. You decide whether it only checks for updates, downloads them to disk, or applies them to the system. The timer runs daily by default. You can adjust the frequency, but daily aligns with Fedora release engineering cadence and keeps your system close to the upstream baseline without overwhelming your bandwidth.
Under the hood, the timer triggers a service that runs a Python script. That script calls dnf with specific flags, reads the configuration file, and logs everything to the journal. If the configuration says mode=apply, the script will attempt to install available updates. If a dependency conflict blocks the transaction, the script aborts and leaves the system untouched. It will not force a broken package into place. This safety mechanism is why you can enable automatic updates without fearing a corrupted root filesystem.
The architecture separates scheduling from execution. The .timer unit handles the clock. The .service unit handles the work. This separation is a systemd convention that keeps resource usage low. The timer sleeps until its next trigger. It consumes zero CPU and negligible memory. When the trigger fires, systemd starts the service, the script runs, and the service exits. The timer then goes back to sleep. You never run the service directly. You only interact with the timer.
The fix or how-to
The default Fedora Workstation and Server images include dnf-automatic. Verify it is present before configuring anything.
rpm -q dnf-automatic # Confirms the package is installed and shows the version
If the command returns package dnf-automatic is not installed, run sudo dnf install dnf-automatic. Most systems already have it. The next step is configuring the behavior. The configuration file lives in /etc/dnf/automatic.conf. Files in /etc/ are meant for user modification. Files in /usr/lib/ ship with the package and will be overwritten on upgrade. Always edit the /etc/ copy.
Open the configuration file in your preferred editor. You will see several commented lines. The only line that requires immediate attention is the mode setting. Uncomment it and set it to apply. This tells the update script to install packages automatically.
# /etc/dnf/automatic.conf
# Uncomment and set to 'apply' to automatically install updates
mode=apply
# Controls whether the system reboots after critical updates
# Set to 'never' if you manage reboots manually
reboot=when-needed
# Adds a random delay to prevent all machines from hitting mirrors simultaneously
random_sleep=300
The mode parameter accepts three values. check only verifies that updates exist and sends a notification. download pulls the packages to the local cache but does not install them. apply installs the updates and reboots if a kernel or critical system library requires it. Choose apply only if your system is a standard installation without custom repositories or third-party kernel modules.
After saving the configuration, enable the timer. The timer controls when the update check runs. The service runs the actual update logic. Enabling the timer starts the schedule.
sudo systemctl enable --now dnf-automatic.timer # Activates the daily update schedule and starts it immediately
You do not need to enable the service manually. The timer triggers it. If you want to verify the schedule, check the timer state.
systemctl list-timers --all | grep dnf-automatic # Shows the next scheduled run and last trigger
The output will display the next elapse time and the last trigger. The default schedule runs once per day. You can override the default by creating a drop-in configuration file for the timer unit, but the daily cadence works for 95 percent of desktop and server workloads.
Run journalctl first. Read the actual error before guessing.
Verify it worked
Automatic updates run silently. You will not see a terminal window pop up. You will not hear a fan spin up. Verification requires checking the journal logs and the package manager cache. Run the following command to see the most recent execution log.
journalctl -u dnf-automatic.service --since "today" # Filters logs to the current day for the update service
Look for lines that say Updating system. followed by Complete. If the service ran successfully, you will see a summary of installed packages. If you see Nothing to do, the system is already up to date. This is normal. Fedora releases updates in batches. Not every day brings a new package.
Check the package manager cache to confirm the downloaded metadata matches the repositories.
dnf check-update # Forces a manual refresh and lists available updates
If dnf check-update returns an empty list, the automatic update already applied the latest packages. If it lists packages, the automatic run either failed or has not triggered yet. Wait for the next scheduled window or run the timer manually for immediate testing.
sudo systemctl start dnf-automatic.timer # Forces the timer to trigger immediately for testing
When debugging service failures, journalctl -xe reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. It gives you context without scrolling through unrelated boot messages.
Common pitfalls and what the error looks like
Automatic updates will not break a standard Fedora installation. They will break a customized one. If you are running a third-party kernel, a custom NVIDIA driver from a COPR repository, or a manually compiled module, dnf-automatic will attempt to replace the official packages. The transaction test will fail. The service will log a conflict and exit. Your system will remain on the old version. You will not get a warning email unless you configure one.
The most common failure mode is a repository mismatch. You add a third-party repo, it provides a package that conflicts with a Fedora base package, and the automatic update tries to resolve it. The dnf transaction test catches it. The log will show something like this:
Error: Transaction test error:
package kernel-6.8.5-200.fc39.x86_64 conflicts with kernel-custom provided by akmod-nvidia-545.23.08-1.fc39.x86_64
When this happens, the automatic update stops. It does not roll back partially installed packages. It leaves the system exactly as it was before the timer fired. You must resolve the conflict manually. Run sudo dnf upgrade --refresh to force a metadata refresh and attempt the transaction with full visibility. If the conflict persists, exclude the problematic package from automatic updates or remove the third-party repository.
Another pitfall is disk space exhaustion. The dnf-automatic service downloads packages to /var/cache/dnf. If you run automatic updates on a machine with a small root partition, the cache can fill up. The next update will fail with Error: No space left on device. Clean the cache periodically.
sudo dnf clean all # Removes cached metadata and downloaded packages
Fedora's release cadence is 6 months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle. Automatic updates only handle point releases within the same Fedora version. They will not upgrade you from Fedora 40 to Fedora 42. For crossing major releases, you must use dnf system-upgrade. They are different commands. Don't conflate them.
SELinux does not interfere with dnf-automatic. The service runs as root and uses standard package manager paths. If you see denials in the journal, they are unrelated to the update process. Check journalctl -t setroubleshoot for actual security context violations. SELinux denials show up with a one-line summary. Read those before disabling SELinux. The two systems operate in separate domains.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use automatic updates with mode=apply when you run a standard Fedora Workstation or Server installation and want zero-touch security patching. Use mode=download when you want to conserve bandwidth during off-hours and prefer to apply updates during a maintenance window. Use mode=check when you run a production server with strict change management and need email notifications before any package changes. Use manual dnf upgrade --refresh when you maintain custom repositories, compile kernel modules, or need to review changelogs before applying updates. Stay on the default manual schedule if you only deviate from the base packages occasionally and prefer full control over every transaction.
Snapshot the system before the upgrade. Future-you will thank you.