dnf-automatic: Sicherheitsupdates auf Rocky und Alma

Was dnf-automatic unter Rocky Linux und AlmaLinux macht

Mit dnf-automatic erhalten Sie unbeaufsichtigte Sicherheitsupdates unter Rocky Linux und AlmaLinux. Es ist ein kleines Programm, das von einem systemd-Timer gestartet wird, /etc/dnf/automatic.conf liest und die dort erlaubten Aktionen ausführt. Die Installation erfordert einen einzigen Befehl. Der restliche Teil dieses Leitfadens behandelt die Einstellungen, die entscheiden, ob der Server geschützt wird oder das Programm unbemerkt nichts tut.

Wenn Sie von Debian oder Ubuntu kommen: Diese Aufgabe übernimmt unattended-upgrades auf einem Ubuntu-VPS. Ein Unterschied ist wichtiger als alle anderen: Es geht darum, was das Wort „security“ für den Paketmanager bedeutet. Unter Ubuntu ist „security“ ein separates Archiv-Repository. In der RHEL-Familie sind Sicherheitsinformationen Metadaten, die veröffentlichten Advisories zugeordnet sind. Diese Metadaten können fehlen oder veraltet sein. Wenn Sie dnf-automatic auf ein Repository ohne Advisory-Daten verweisen, installiert es nichts und meldet trotzdem Erfolg.

Dieser Leitfaden bezieht sich auf Rocky Linux 9 und AlmaLinux 9, die DNF 4 verwenden (DNF ist der Paketmanager der RHEL-Familie), Stand August 2026. Die Versionen 10 verwenden DNF5, und dort ändern sich die Bezeichnungen. Deshalb gibt es dafür am Ende einen eigenen Abschnitt. Jeder folgende Befehl wird auf Ihrem eigenen Server ausgeführt. Die erwartete Ausgabe steht jeweils daneben.

dnf-automatic installieren und die mitgelieferte Konfiguration lesen

Das Aktivieren automatischer Updates gehört zusammen mit den übrigen Einrichtungsschritten in die ersten zehn Minuten auf einem neuen VPS, direkt nachdem Sie einen Nicht-root-Benutzer und eine Firewall eingerichtet haben. Falls die Firewall noch nicht eingerichtet ist: firewalld wird mit Rocky und AlmaLinux ausgeliefert, und einige Befehle öffnen SSH, den Port, auf dem Ihre Website Verbindungen annimmt, und sorgen dafür, dass diese Einstellungen einen Reboot überstehen.

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

systemctl is-enabled gibt bei einer frischen Installation disabled aus, weil die Installation des Pakets keinen Dienst startet. Das ist der häufigste Grund dafür, dass ein Server, auf dem „dnf-automatic“ installiert ist, noch kein einziges Update angewendet hat.

Die DNF-Version ist für eine Option relevant. Die Einstellung reboot wurde mit DNF 4.15 upstream eingeführt. Red Hat hat sie im November 2023 über das Advisory RHBA-2023:6645 in dnf-4.14.0-6.el9 zurückportiert. Rocky 9 und AlmaLinux 9 bauen dieses Paket neu. Ein aktuelles System unterstützt die Einstellung daher, ein seit 2023 nicht aktualisiertes System jedoch nicht.

Die Konfigurationsdatei ist /etc/dnf/automatic.conf. Die mitgelieferte Datei enthält jede Option, die dieser Build unterstützt, jeweils mit auskommentiertem Standardwert. Lesen Sie sie einmal, bevor Sie sie bearbeiten. Diese Datei ist die maßgebliche Dokumentation für Ihre Version.

Die beiden Schalter, die das Verhalten festlegen

download_updates und apply_updates im Abschnitt [commands] legen das Verhalten fest. Unter EL9 (Enterprise Linux 9, die gemeinsame Basis von Rocky 9 und AlmaLinux 9) sind beide standardmäßig no. Ein unverändertes, aktiviertes dnf-automatic meldet daher nur verfügbare Updates.

• Beide no: dnf-automatic meldet verfügbare Updates und ändert nichts am System.
• download_updates = yes mit apply_updates = no: Die Pakete werden in den DNF-Cache geladen. Die Installation geht danach schnell und benötigt kein Netzwerk, aber in dieser Nacht wurde nichts geändert.
• Beide yes mit upgrade_type = default: Jedes verfügbare Update wird installiert, unabhängig davon, ob es sich um ein Security-Update handelt.
• Beide yes mit upgrade_type = security: Nur Pakete, die in einem Security Advisory genannt werden, werden installiert.

Ein sinnvoller Ausgangspunkt für einen öffentlich erreichbaren VPS:

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

network_online_timeout gibt an, wie viele Sekunden der Lauf auf ein funktionierendes Netzwerk wartet, bevor er abbricht. Das ist bei einem System wichtig, das gerade gestartet wurde. random_sleep ist eine ältere Methode, die Last auf viele Systeme zu verteilen. Diese Aufgabe übernimmt jetzt der Timer. Führen Sie systemctl cat dnf-automatic.service aus, um die exakten Flags anzuzeigen, die der ausgelieferte Dienst übergibt.

Prüfen Sie die Datei, ohne bis 06:00 zu warten:

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

Das Journal zeigt, welche Updates der Lauf geprüft und welche Aktionen er ausgeführt hat. Sie können ein Verhalten auch über die Befehlszeile erzwingen. Das überschreibt die Datei nur für diesen Lauf:

sudo dnf-automatic --downloadupdates --no-installupdates

Was upgrade_type = security auf Rocky und Alma wirklich bedeutet

DNF erkennt anhand von Versionsnummern nicht, ob es sich bei einem Update um ein Security-Update handelt. Stattdessen liest es Errata-Metadaten: eine Datei namens updateinfo.xml, die innerhalb des Repositorys veröffentlicht wird und in der jedes Advisory die Pakete aufführt, die das Problem beheben. AlmaLinux veröffentlicht diese als ALSA-Advisories, Rocky als RLSA. upgrade_type = security erstellt aus diesen Metadaten einen Filter und aktualisiert nur die Pakete, auf die dieser Filter zutrifft.

Daraus ergeben sich zwei Konsequenzen, die viele zunächst überraschen.

Erstens gibt es ohne Metadaten keine Updates. Wenn das Repository kein updateinfo.xml enthält, trifft der Filter auf nichts zu. Der Lauf endet dann mit dieser Zeile im Journal:

No security updates needed, but 3 updates available

Das System ist nicht gepatcht, und es wurde kein Fehler gemeldet. Prüfen Sie es selbst:

dnf updateinfo list --security
dnf check-update

Wenn dnf check-update Pakete auflistet, während dnf updateinfo list --security überhaupt nichts ausgibt, trägt entweder kein ausstehendes Update ein Advisory, oder das Repository enthält keine Advisory-Daten, die gelesen werden können. Rocky und AlmaLinux veröffentlichen diese Daten beide. Bei diesen beiden Distributionen ist eine leere Liste daher normalerweise korrekt. CentOS Stream veröffentlicht sie überhaupt nicht.

Zweitens ist der Security-Modus keine minimale Änderung. dnf-automatic fügt den Security-Filter hinzu und führt anschließend den normalen Upgrade-Pfad aus. Ein in einem Advisory genanntes Paket wird daher auf die neueste Version im Repository aktualisiert und zieht dabei seine Abhängigkeiten mit. Der kleinere Schritt, also nur auf die früheste Version zu aktualisieren, die das Advisory behebt, ist dnf upgrade-minimal --security, das Sie manuell ausführen müssen. dnf-automatic bietet dafür keine Einstellung.

Für Rocky gilt außerdem ein weiterer Vorbehalt. Rocky erzeugt seine Errata über eine eigene Pipeline aus Red-Hat-Daten. Diese Pipeline ist in Rückstand geraten. Im September 2025 berichteten Benutzer, dass sich das Rocky 9 BaseOS updateinfo.xml seit Dezember 2024 nicht verändert hatte. Dadurch fehlten --security aktuelle Advisories. Mitarbeiter von Rocky bestätigten, dass es sich um ein bekanntes Problem handelt. Wenn Sie auf upgrade_type = security angewiesen sind, vergleichen Sie die Advisory-Liste gelegentlich mit den aktuellen RLSA-Ankündigungen. Auf einem System, bei dem die Abdeckung wichtiger ist als die Kontrolle über Änderungen, ist upgrade_type = default nach einem Zeitplan Ihrer Wahl die sicherere Einstellung.

Der systemd-Timer, der den Vorgang tatsächlich ausführt

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

list-timers sollte eine Zeile mit einer NEXT Zeit ausgeben, die etwa einen Tag in der Zukunft liegt. Eine leere Tabelle bedeutet, dass der Timer nicht aktiviert ist. Der Vorgang wird dann nie ausgeführt.

Der mitgelieferte Timer wird um *-*-* 6:00 mit RandomizedDelaySec=60m und Persistent=true ausgelöst. Die zufällige Verzögerung verteilt die Server innerhalb einer Stunde, damit nicht jeder Server in derselben Sekunde auf den Mirror zugreift. Persistent=true bedeutet: Ein Rechner, der um 06:00 ausgeschaltet war, führt den verpassten Vorgang kurz nach dem Booten aus, statt ihn für diesen Tag zu überspringen.

Ändern Sie den Zeitplan mit einem Drop-in. Bearbeiten Sie die mitgelieferte Unit nicht, weil ein Paket-Upgrade Dateien unter /usr/lib/systemd/system ersetzt.

sudo systemctl edit dnf-automatic.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

Die leere Zeile OnCalendar= ist erforderlich. OnCalendar sammelt Werte an. Ohne diese Zurücksetzung bleibt der Eintrag für 06:00 erhalten, und ein zweiter Eintrag kommt hinzu. Der Vorgang wird dann zweimal täglich ausgeführt. Bestätigen Sie das Ergebnis mit systemctl list-timers dnf-automatic.timer und lesen Sie die Spalte NEXT. Für alle anderen geplanten Vorgänge gelten dieselben Drop-in-Regeln. Diese werden unter systemd-Service- und Timer-Units schreiben beschrieben.

Nun zur Falle. Das Paket liefert drei weitere Timer mit: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer und dnf-automatic-install.timer. Jeder startet dasselbe Programm mit Kommandozeilenoptionen. Diese Optionen überschreiben download_updates und apply_updates aus Ihrer Konfigurationsdatei. Aktivieren Sie einen davon zusätzlich zu dnf-automatic.timer, wird der Vorgang zweimal mit unterschiedlichem Verhalten ausgeführt. Das sieht genau so aus, als würde Ihre Konfigurationsdatei ignoriert. Aktivieren Sie einen Timer und prüfen Sie:

systemctl list-unit-files 'dnf-automatic*'

Wann wurde etwas installiert?

emit_via im Abschnitt [emitters] steuert die Berichterstattung. Unter systemd schreibt der stdio-Emitter in das Journal. Das ist die zuverlässige Option, weil dafür nichts anderes installiert sein muss:

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

Der motd-Emitter schreibt den Bericht nach /etc/motd und ersetzt den Inhalt dieser Datei. Wenn Sie dort ein Login-Banner vorhalten, lassen Sie diesen Emitter weg.

Der email-Emitter baut eine SMTP-Verbindung (Simple Mail Transfer Protocol) zu email_host über email_port auf. Standardwerte sind localhost und 25. Auf einem neuen VPS lauscht dort normalerweise nichts. Daher wird die Verbindung abgelehnt und keine E-Mail versendet. Führen Sie ss -lnt | grep ':25' aus, bevor Sie sich darauf verlassen. Richten Sie außerdem ein Relay-only-Postfix ein, wenn die Ausgabe leer bleibt. Wenn der E-Mail-Versand funktioniert, lautet der Betreff Updates applied on 'web01'.. Der Name wird aus system_name übernommen.

Für alle anderen Fälle übergibt der command-Emitter den Bericht über die Standardeingabe an ein eigenes Programm:

[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes

[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}

send_error_messages ist standardmäßig auf no gesetzt. Das bedeutet, dass ein fehlgeschlagener Lauf überhaupt nichts meldet. Aktivieren Sie diese Option. Ein Patchsystem, das nur Erfolge meldet, ist schlechter als keines, weil das Ausbleiben einer Meldung als ordnungsgemäßer Zustand verstanden wird.

dnf-automatic startet Ihre Dienste nicht neu

Die Installation eines Pakets ersetzt Dateien auf der Festplatte. Ein bereits laufender Prozess behält den alten Code im Speicher. Eine aktualisierte Bibliothek hat daher keine Wirkung auf einen Daemon, der im letzten Monat gestartet wurde. Diese Lücke zwischen installiertem und tatsächlich wirksamem Code ist der Grund, warum automatisierte Updates eine Neustart-Richtlinie und nicht nur eine Installationsrichtlinie benötigen.

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

-s listet die systemd-Dienste auf, deren Dateien geändert wurden, nachdem sie gestartet wurden. -r beantwortet eine Frage und gibt einen von zwei Blöcken aus:

Core libraries or services have been updated since boot-up:
  * kernel
Reboot is required to fully utilize these updates.

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

-r ist keine tiefgehende Analyse. Der Befehl prüft eine feste Paketliste: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon und microcode_ctl. Wenn eines dieser Pakete nach dem letzten Boot installiert wurde, erhalten Sie die erste Antwort. Fügen Sie eigene Paketnamen in einer Datei mit der Endung .conf unter /etc/dnf/plugins/needs-restarting.d/ hinzu, wenn auch etwas anderes auf dem System einen Neustart benötigt, damit die Änderung wirksam wird.

Ein wichtiger Hinweis für Skripte: dnf needs-restarting -r beendet sich sowohl bei erforderlichem Neustart als auch bei einem Fehler des Befehls mit einem Status ungleich null. Der Exit-Status allein kann diese Fälle daher nicht unterscheiden. Lesen Sie den ausgegebenen Text.

Ein Dienstneustart ist der kleinere Eingriff und normalerweise die richtige Maßnahme. Starten Sie den SSH-Daemon aus einer zweiten, bereits geöffneten SSH-Sitzung neu. So sperrt Sie eine fehlerhafte Konfiguration nicht aus. Bei einem neuen Kernel hilft nur ein Reboot, weil der laufende Kernel nicht im laufenden Betrieb ersetzt werden kann. Wenn Sie die Updates eines bestimmten Morgens in diese beiden Kategorien einteilen möchten, arbeitet welche Updates einen Reboot benötigen und welche nur einen Dienstneustart benötigen die Ausgabe paketweise durch.

Container sind ein separater Fall. dnf-automatic aktualisiert die Pakete des Hosts und verändert niemals den in einem Image enthaltenen Userland-Code. Ein System mit Docker Engine auf Rocky Linux oder AlmaLinux benötigt daher ebenfalls erneut gezogene Images und neu erstellte Container, bevor eine Korrektur den Code erreicht, der den Netzwerkverkehr tatsächlich verarbeitet.

Soll der Server automatisch neu starten?

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

reboot = never ist die Standardeinstellung. when-changed startet den Server nach jedem installierten Update neu. when-needed startet ihn nur neu, wenn die Prüfung hinter needs-restarting -r feststellt, dass ein Kernpaket ersetzt wurde. Das ist für die meisten Betreiber eines einzelnen Servers die gewünschte Einstellung, kombiniert mit einem selbst festgelegten Zeitfenster für den Timer. reboot_command warnt angemeldete Benutzer über shutdown standardmäßig fünf Minuten vorher. Dieses Intervall können Sie verlängern.

Klären Sie zwei Punkte, bevor Sie die Einstellung aktivieren. Jeder benötigte Dienst muss beim Systemstart selbstständig gestartet werden. Genau das ist bei einem manuell gestarteten Docker-Compose-Stack häufig nicht der Fall. Außerdem benötigen Sie über Ihren Provider Zugriff auf die Konsole oder den Rettungsmodus. Ein Kernel, der nicht bootet, lässt sich nicht über SSH reparieren. Fehlt eine dieser Voraussetzungen, lassen Sie reboot = never aktiviert und starten Sie den Server erst nach Prüfung des Journals manuell neu.

Rocky, AlmaLinux und CentOS Stream: die Unterschiede

Auf Rocky 9 und AlmaLinux 9 ist alles bisher Beschriebene identisch, bis hin zum Konfigurationspfad und den Unit-Namen. Beide veröffentlichen Errata, daher enthält upgrade_type = security Daten, die gefiltert werden können. Das zuvor beschriebene veraltete Rocky-Erratum ist eine der wenigen Stellen, an denen sich ihr Verhalten im täglichen Betrieb tatsächlich unterscheidet. Wenn der Server noch nicht eingerichtet ist, sollten Sie dies zusammen mit dem Kompatibilitätsversprechen und der Unterstützung älterer CPUs berücksichtigen, die die beiden Distributionen unterscheiden.

CentOS Stream ist die Ausnahme, und zwar eine grundlegende. Die Stream-Repositorys enthalten keine updateinfo.xml. Daher kann der Security-Filter nie greifen, und jeder Lauf meldet No security updates needed. Verwenden Sie auf Stream upgrade_type = default und akzeptieren Sie, dass damit jedes Update installiert wird. Stream liegt außerdem vor RHEL. Daher ändert sich diese Einstellung auf einem Stream-Server stärker als dieselbe Einstellung auf Rocky oder AlmaLinux. Dieser Unterschied ist kein zufälliges Ergebnis der Paketierung, sondern geht auf Red Hats Entscheidung von 2020 zurück, CentOS in eine Rolling Preview von RHEL umzuwandeln. Es handelt sich um dieselbe Entscheidung, durch die Rocky Linux und AlmaLinux entstanden sind.

Rocky 10 und AlmaLinux 10 verwenden DNF5, das einige Bezeichnungen ändert. Die DNF5-Dokumentation des Upstream-Projekts nennt den Timer dnf5-automatic.timer, legt die mitgelieferten Standardwerte in /usr/share/dnf5/dnf5-plugins/automatic.conf ab, während Ihre Überschreibungen weiterhin in /etc/dnf/automatic.conf stehen, setzt download_updates standardmäßig auf yes statt auf no und ergänzt distro-sync als upgrade_type. Die Abfrage für Advisories lautet dnf advisory list, wobei updateinfo als Alias erhalten bleibt. Prüfen Sie, was Ihre Version tatsächlich installiert hat, bevor Sie Paket- oder Unit-Namen aus einer Anleitung für Version 9 übernehmen:

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

Viele veröffentlichte Anleitungen zu diesem Thema behandeln weiterhin nur Rocky 8. Die Anzahl der Optionen ist seit ihrer Veröffentlichung gestiegen. Prüfen Sie daher die auskommentierte Datei auf Ihrem eigenen Server, statt einem alten Artikel zu vertrauen.

Fehlerbilder und die angezeigten Zeichenfolgen

Nichts wird ausgeführt. systemctl list-timers dnf-automatic.timer gibt eine leere Tabelle aus, und systemctl is-enabled dnf-automatic.timer gibt disabled aus. Das Paket wurde installiert, der Timer jedoch nie.

Der Job läuft und installiert nichts. Im Journal steht No security updates needed, but 3 updates available. Der Sicherheitsfilter hat nichts gefunden. Entweder betrifft kein ausstehendes Update einen Security Advisory, oder das Repository stellt keine Advisory-Daten bereit.

Eine Einstellung scheint ignoriert zu werden. DNF protokolliert bei aktiviertem Debug-Level eine unbekannte Option in automatic.conf und verwendet anschließend den Standardwert. Ein falsch geschriebener Schlüssel ändert daher nichts und erzeugt keine Warnung. Schreiben Sie apply_update = yes, und apply_updates bleibt auf no. Dadurch lädt der Server dauerhaft Updates herunter, installiert sie jedoch nie. Führen Sie nach jeder Änderung sudo systemctl start dnf-automatic.service aus, und lesen Sie das Journal, statt der Datei zu vertrauen.

Der Job läuft zweimal täglich. Zwei Timer sind aktiviert. systemctl list-unit-files 'dnf-automatic*' zeigt an, welche das sind. Die zusätzlichen Timer übergeben Flags, die Ihre Konfigurationsdatei außer Kraft setzen.

Es kommt keine E-Mail an. Entweder lauscht für den email-Emitter kein Prozess auf Port 25, oder send_error_messages steht weiterhin auf no und das einzige berichtenswerte Ereignis war ein Fehler.

Ein gepatchter Dienst meldet weiterhin die alte Version. Die Datei auf dem Datenträger ist neu, der Prozess im Arbeitsspeicher jedoch alt. dnf needs-restarting -s nennt die Dienste, die neu gestartet werden müssen.

FAQ

Installiert dnf-automatic unter Rocky Linux nur Sicherheitsupdates?

Nur wenn Sie upgrade_type = security in /etc/dnf/automatic.conf setzen und Ihre Paketquellen Errata-Metadaten veröffentlichen. Rocky Linux und AlmaLinux veröffentlichen diese Metadaten. Daher kann der Filter die passenden Advisories ermitteln. Der mitgelieferte Standardwert ist upgrade_type = default. Damit wird jedes verfügbare Update installiert, sobald apply_updates = yes.

Warum meldet dnf-automatic „No security updates needed, but 3 updates available“?

DNF ermittelt Sicherheitsupdates anhand von updateinfo.xml aus dem Repository. Jedes Advisory führt die Pakete auf, mit denen das Advisory behoben wird. Fehlen diese Metadaten oder sind sie veraltet, findet der Sicherheitsfilter keine Treffer. Normale Updates können trotzdem ausstehen. Dann wird genau diese Meldung ausgegeben. Das ist bei CentOS Stream zu erwarten, weil dort überhaupt keine Errata veröffentlicht werden. Vergleichen Sie unter Rocky oder AlmaLinux dnf updateinfo list --security mit dnf check-update und prüfen Sie, ob Ihre Metadaten aktuell sind.

Startet dnf-automatic meinen Server nach einem Kernel-Update neu?

Nur wenn Sie dies konfigurieren. Die Option reboot hat standardmäßig den Wert never. Setzen Sie reboot = when-needed. Dann startet ein Lauf den Server nur neu, wenn die Prüfung hinter dnf needs-restarting -r feststellt, dass seit dem Booten ein zentrales Paket wie kernel oder glibc ersetzt wurde. reboot = when-changed startet den Server nach jedem angewendeten Update neu. Beide Optionen verwenden reboot_command. Der Standardwert ist shutdown -r +5; angemeldete Benutzer erhalten eine Warnmeldung.

Wie ändere ich die Ausführungszeit von dnf-automatic?

Führen Sie sudo systemctl edit dnf-automatic.timer aus und fügen Sie einen Abschnitt [Timer] mit einer leeren Zeile OnCalendar= und anschließend Ihrem Zeitplan hinzu, zum Beispiel OnCalendar=*-*-* 03:30. Die leere Zeile ist erforderlich, weil OnCalendar die Werte akkumuliert. Wenn Sie sie weglassen, bleibt der mitgelieferte Lauf um 06:00 Uhr erhalten und ein zweiter Lauf wird hinzugefügt. Prüfen Sie die Konfiguration mit systemctl list-timers dnf-automatic.timer und lesen Sie die Spalte NEXT.

Muss ich einen Server weiterhin prüfen, wenn er sich selbst patcht?

Ja. dnf-automatic installiert Pakete und beendet seine Arbeit danach. Daemon-Prozesse werden nicht neu gestartet. Außerdem erhalten Sie nur dann eine Meldung, wenn emit_via einen Emitter angibt, dessen Ausgaben Sie tatsächlich prüfen. Setzen Sie mindestens emit_via auf stdio. Aktivieren Sie außerdem send_error_messages, damit auch Fehler gemeldet werden. Führen Sie nach einem Patch-Fenster dnf needs-restarting -s aus, um Dienste zu finden, die weiterhin alten Code ausführen.