systemctl, wie man demaskiert

root@gcomputer:~# systemctl status x11-common
● x11-common.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

Ich habe es versucht systemctl unmask x11-commonund systemctl unmask x11-common.servicedas hat aber nichts geändert.

Wie demaskiere ich es?

systemd

— Albert
quelle

Die Befehle, die Sie verwenden, sind beide korrekt . Siehe auch das Handbuch .

Es scheint, dass der unmaskBefehl fehlschlägt, wenn im System keine andere Unit-Datei als der Symlink zu vorhanden ist /dev/null. Wenn Sie maskein Dienst sind, erstellt dies einen neuen Symlink zu, /dev/nullin /etc/systemd/systemdem systemd nach Unit-Dateien sucht, die beim Booten geladen werden sollen. In diesem Fall gibt es keine echte Unit-Datei.

Andere scheinen ähnliche Probleme zu haben

x11-common.servicewurde auch auf meinem system maskiert. Sie können dies folgendermaßen beheben:

Überprüfen Sie zunächst, ob die Unit-Datei einen Symlink zu enthält /dev/null

file /lib/systemd/system/x11-common.service

es sollte zurückkehren:

/lib/systemd/system/x11-common.service: symbolic link to /dev/null

In diesem Fall löschen Sie es

sudo rm /lib/systemd/system/x11-common.service

Da Sie eine Unit-Datei geändert haben, müssen Sie Folgendes ausführen:

sudo systemctl daemon-reload

Überprüfen Sie jetzt den Status:

systemctl status x11-common

Wenn nicht angezeigt wird, dass das Paket geladen ist und ausgeführt wird (wenn der Kreis immer noch rot ist), installieren Sie das Paket erneut:

sudo apt-get install --reinstall x11-common

und lade den Daemon erneut

sudo systemctl daemon-reload

und Status noch einmal überprüfen

systemctl status x11-common

Jetzt ist es grün und läuft :) Der Dienst hat keine systemd Unit-Datei, aber systemd verwendet /etc/init.dstattdessen gerne das Skript dafür .

— Zanna
quelle

Ok, folgende Frage: Wenn es auf Ihrem System sogar maskiert war, wozu dient dieser Service? Es scheint nicht wirklich nötig zu sein, wenn es für uns beide maskiert ist.

— Albert

@ Albert [Siehe hier.] ( Askubuntu.com/questions/712276/… ) scheint, dass der Dienst ohne die systemd-Unit-Datei funktioniert (es gibt eine Datei in /etc/init/...). Vielleicht möchten Sie eine neue Frage stellen. Was ich gemacht habe machte keinen offensichtlichen Unterschied, nur der Dienst wird als geladen, aktiviert, gestoppt (es ist beim Start aktiv) (grün) statt als geladen, maskiert, tot (rot) angezeigt. Ich sollte meine Protokolle lesen ...

— Zanna

Wenn ein Update für systemd kommt, wird die Unit-Datei neu installiert, so dass dies nicht wirklich eine strukturelle Lösung ist

— HBOGERT

@hbogert passiert das auch wenn es außer dem symlink zu keine unit datei gab /dev/null? Sie haben jedoch Recht mit meiner Antwort. Ich würde diese Lösung als Problemumgehung für ein ... verwirrendes Verhalten ... von systemd

— Zanna

Könnten Sie Ihren ersten Satz mit genauen Dateien beschreiben, die in diesem Fall von Bedeutung sind (weil ich das von Ihnen beschriebene Szenario nicht wirklich verstehe)?

— HBOGERT

Es könnte sein, dass Ihr Dienst eine leere Überschreibungsdatei hat, wie diese:

● redis-server.service - Erweiterter Schlüsselwertspeicher Geladen: Geladen (/lib/systemd/system/redis-server.service; maskiert; Herstellervoreinstellung: aktiviert) Drop-In: / etc / systemd / system / redis-server .service.d └─limit.conf

Überprüfen Sie, ob limit.conf eine leere Datei ist. Wenn ja, bitte entfernen. Dann sollte der Dienst entlarvt werden.

— Erik Hensema
quelle

Folgen Sie den unteren Schritten:

systemctl edit systemd-hostnamed

Füge die 2 Zeilen darunter hinzu und verlasse den Editor (vergiss nicht zu speichern, wenn du dazu aufgefordert wirst):
```
[Service]
PrivateNetwork=no
```
Dadurch wird eine override.conf-Datei mit den obigen 2 Zeilen im Verzeichnis erstellt:
```
/etc/systemd/system/systemd-hostnamed.service.d/
```
Das Update-Systemd:
```
systemctl daemon-reload
```
Starten Sie dann den Dienst neu:
```
systemctl restart systemd-hostnamed
```

Sie sollten jetzt laufen können, hostnamectlohne dass es hängt.

— Hossein
quelle