yum update changes selinux labels and services fail to start after reboot

TL;DR

If services break after a yum update with SELinux denials in the audit log, the update likely replaced files or a whole tree whose labels no longer match policy - common after packages are extracted manually, files are copied in, or a filesystem was restored. Restore the correct contexts with restorecon on the affected paths, or relabel the filesystem if the damage is wide, then start the services. Check the audit log for the exact denied contexts first so you relabel what is wrong instead of switching SELinux to permissive as a shortcut.

yum update changes selinux labels and services fail to start after reboot

Use this when

• Services fail to start after a yum update and reboot, with AVC denied entries in the audit log timestamped at the failures.
• ausearch or audit2why explains denials involving the updated package files or their data directories.
• The same services start normally when SELinux is temporarily permissive during a diagnostic boot, confirming labels as the cause.

Not for this skill when

• No AVC denials exist and the service fails on its own configuration error. Fix the service configuration.
• SELinux is already disabled on the system by design. Label repair does not apply.

Steps

1. Confirm SELinux is the cause with evidence, not by toggling it off permanently: collect the AVC denials for the failure window with ausearch by time, and run audit2why to translate them. Note the source contexts, target contexts, and paths denied, because the fix must target exactly those labels. Verify: you have specific denied paths and contexts from the audit log, not a general suspicion about SELinux
2. Identify how far the label damage spreads: check contexts on the affected paths with ls -Z and compare them with the contexts policy expects using matchpathcon for the same paths. If only the updated package tree and its data folder are wrong, a targeted relabel is enough; if system-wide paths mismatch, the damage came from something bigger such as a file-level restore. Verify: the scope is classified as targeted paths or system-wide, based on matchpathcon differences
3. Restore labels on the affected paths with restorecon recursively and verbosely, covering the package files and any data, log, and runtime directories the service owns. For a service whose files live in a home directory or custom path, confirm policy has a rule for that path or add a proper file context rule with semanage before relabeling, otherwise restorecon will apply the generic context again. Verify: restorecon reports contexts changed to the expected values, and matchpathcon and ls -Z now agree on the fixed paths
4. If the damage is system-wide, schedule a full relabel: create the autorelabel trigger file at the filesystem root and reboot in a maintenance window, understanding the relabel can take significant time on large filesystems. Do this instead of hundreds of targeted fixes when core directories all mismatch. Verify: the system completes a full relabel and reboots into enforcing mode with correct contexts on core paths
5. Start the affected services and watch the audit log live during startup and a realistic operation such as serving a request or writing data. If new denials appear for a legitimate application path, add a proper context rule for that path and relabel it, rather than broadening permissions. Record the paths and rules added in your configuration management so the next update or rebuild keeps them. Verify: services start and run under enforcing mode with no new AVC denials for their normal operations

Why it happens

SELinux labels are stored as extended attributes on files, and policy decisions are made from those labels, not from file names or permissions. A yum update normally preserves correct labels because rpm knows the policy, but labels get broken when files arrive by other routes around the same change - a tar extraction, a file copy with preserved foreign contexts, a restored filesystem, or a package built without proper contexts. After reboot, services confined by SELinux are denied access to their own files and fail in ways that look like application bugs. Restoring labels from policy re-aligns the filesystem with what the services are allowed to touch, which is why relabeling fixes it and permissive mode only hides it.

Variants and edge cases

Labels broken only in a web or application content folder

Content deployed by copying files in often carries the wrong context. Set a persistent file context rule for the content path so every future deployment lands with the right label.

Denials after restoring the system from a file backup

Backups that do not preserve extended attributes strip labels wholesale. Plan a full autorelabel after any such restore as a standard step.

Service works in permissive, fails in enforcing, no AVC logged

Auditing may be suppressing denials through dontaudit rules. Temporarily enable full auditing of denials during diagnosis rather than concluding SELinux is innocent.

Compatibility: Applies to Red Hat Enterprise Linux 8 and 9, Rocky Linux, AlmaLinux, and Fedora with SELinux in enforcing mode, updated with yum or dnf.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstiSU4wNWPvCAbKTwMhBdoQ