Ich habe eine override.confDatei für erstellt systemd-journal-catalog-update.serviceund in das Verzeichnis gelegt systemd-journal-catalog-update.service.d/. Der Zweck ist es, systemd-tmpfiles-setup.serviceaus demsystemd-journal-catalog-update.service file.
Die Datei enthält jetzt Folgendes:
[Unit]
After=local-fs.target systemd-tmpfiles-setup.service
Meine override.confDatei enthält Folgendes:
[Unit]
After=
After=local-fs.target
systemd-journal-catalog-update.serviceDie Datei scheint sich jedoch nicht zu ändern. Habe ich ein falsches Verständnis override.conffür die Funktionsweise der Datei? Ich weiß, dass ich die ursprüngliche Servicedatei manuell ändern kann, aber die Umstände des Projekts schränken diese Option ein. Für jede Hilfe/jeden Ratschlag, den Sie mir geben können, bin ich sehr dankbar.
Antwort1
Was Sie wollen (Entfernen einer Abhängigkeit von der Einheit über eine Drop-In-Datei) ist nicht möglich, gemäß dersystemd.unitManpage:
Abhängigkeiten (After=, etc.) können nicht auf eine leere Liste zurückgesetzt werden, daher können Abhängigkeiten nur in Drop-Ins hinzugefügt werden. Wenn Sie Abhängigkeiten entfernen möchten, müssen Sie die gesamte Einheit überschreiben.
Das Überschreiben einer gesamten Unit-Datei kann durch Befolgen des zweiten Beispiels auf der Manpage erfolgen:
Es gibt zwei Methoden, um Vendor-Einstellungen in Unit-Dateien zu überschreiben: Kopieren der Unit-Datei von /usr/lib/systemd/system nach /etc/systemd/system und Ändern der gewählten Einstellungen. [...] Der Vorteil der ersten Methode ist, dass man ganz einfach die komplette Unit überschreibt, die Vendor-Unit wird überhaupt nicht mehr analysiert. Sie hat den Nachteil, dass Verbesserungen der Unit-Datei durch den Vendor bei Updates nicht automatisch eingearbeitet werden.
In Ihrem Fall müssen Sie (als Root)
cp /usr/lib/systemd/system/systemd-journal-catalog-update.service /etc/systemd/systemsystemctl daemon-reloadsystemctl restart systemd-journal-catalog-update
Danach systemctl statuswird auf die Servicedatei in folgendem Verzeichnis verwiesen /etc:
# systemctl status systemd-journal-catalog-update
● systemd-journal-catalog-update.service - Rebuild Journal Catalog
Loaded: loaded (/etc/systemd/system/systemd-journal-catalog-update.service; static)
Active: active (exited) since Sat 2021-05-22 16:27:07 CEST; 3 weeks 2 days ago
[...]
Das oben genannte systemctl catzeigt die Datei auch nicht an in /etc/:
# systemctl cat systemd-journal-catalog-update
# /etc/systemd/system/systemd-journal-catalog-update.service
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Rebuild Journal Catalog
[...]
Sie können die Datei nun /etcnach Wunsch bearbeiten, systemctl daemon-reloaderneut ausführen und systemctl restart systemd-journal-catalog-updateden Dienst mit Ihrer benutzerdefinierten Unit-Datei und deren Einstellungen ausführen.
Beachten Sie Folgendes, was auf der Manpage erwähnt wird:
Dies hat den Nachteil, dass Verbesserungen der Unit-Datei durch den Hersteller nicht automatisch bei Updates einfließen.
Da systemd jetzt eine völlig andere Unit-Datei liest als die im systemd-Paket Ihrer Distribution, müssen Sie alle Aktualisierungen aus der Datei manuell /usr/libauf Ihre eigene Kopie anwenden. .rpmnew(von RPM-basierten Distributionen) oder .pacnew(von Pacman-basierten Distributionen) Dateien, die normalerweise generiert werden, wenn eine vom Paketmanager verfolgte Konfigurationsdatei sowohl vom lokalen Administrator als auch vom Paket geändert wurde, werden in diesem Fall nicht generiert.