systemctl, jak zdemaskować

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

Próbowałem systemctl unmask x11-commoni systemctl unmask x11-common.servicenic to nie zmieniło.

Jak to zdemaskować?

systemd

— Albert
źródło

Użyte polecenia są poprawne . Zobacz także instrukcję .

Wygląda na to, że unmaskpolecenie kończy się niepowodzeniem, gdy w systemie nie ma pliku jednostki innego niż dowiązanie symboliczne do /dev/null. Jeśli jesteś maskusługą, to tworzy nowe łącze symboliczne do miejsca, /dev/nullw /etc/systemd/systemktórym systemd szuka plików jednostkowych do załadowania podczas rozruchu. W takim przypadku nie ma pliku rzeczywistej jednostki.

Inni wydają się mieć podobne problemy

x11-common.servicezostał również zamaskowany w moim systemie. Możesz to naprawić w następujący sposób:

Najpierw sprawdź, czy plik jednostkowy jest dowiązaniem symbolicznym /dev/null

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

powinien zwrócić:

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

w takim przypadku usuń go

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

Ponieważ zmieniłeś plik jednostki, musisz uruchomić to:

sudo systemctl daemon-reload

teraz sprawdź status:

systemctl status x11-common

jeśli nie wyświetla się komunikat o załadowaniu i uruchomieniu (jeśli kółko jest nadal czerwone), zainstaluj ponownie pakiet:

sudo apt-get install --reinstall x11-common

i ponownie załaduj demona

sudo systemctl daemon-reload

i jeszcze raz sprawdź status

systemctl status x11-common

Teraz jest zielony i działa :) Usługa nie ma pliku jednostki systemowej, ale systemd chętnie używa do tego skryptu /etc/init.d.

— Zanna
źródło

Ok, kolejne pytanie: jeśli w twoim systemie było nawet zamaskowane, do czego służy ta usługa? Wydaje się, że nie jest tak naprawdę potrzebny, jeśli jest zamaskowany dla nas obu.

— Albert

@Albert [Zobacz tutaj.] ( Askubuntu.com/questions/712276/… ) wydaje się, że usługa działa bez pliku systemowej jednostki (ma plik w /etc/init/...). Możesz zadać nowe pytanie. To, co zrobiłem, nie robi widocznej różnicy, tylko usługa pokazuje, że jest załadowana, włączona, zatrzymana (jest aktywna przy uruchomieniu) (zielona) zamiast załadowanej zamaskowanej martwej (czerwona). Powinienem przeczytać moje logi ...

— Zanna,

jeśli pojawi się aktualizacja dla systemd, plik jednostki jest ponownie instalowany, więc nie jest to tak naprawdę rozwiązanie strukturalne

— hbogert

@hbogert, czy tak się dzieje, nawet jeśli nie ma pliku jednostkowego oprócz dowiązania symbolicznego do /dev/null? Masz jednak rację co do mojej odpowiedzi. Nazwałbym to rozwiązanie obejściem ... mylącego zachowania ... systemd

— Zanna

Czy mógłbyś opisać swoje pierwsze zdanie w kategoriach dokładnych plików, które mają znaczenie w tym przypadku (ponieważ tak naprawdę nie rozumiem scenariusza, który opisujesz)?

— hbogert

Być może Twoja usługa ma pusty plik zastępowania, taki jak ten:

● redis-server.service - Zaawansowany magazyn klucz-wartość Załadowano: załadowano (/lib/systemd/system/redis-server.service; zamaskowany; preset dostawcy: włączony) Drop-In: / etc / systemd / system / redis-server .service.d └─limit.conf

Sprawdź, czy limit.conf jest pustym plikiem. Jeśli tak, usuń go. Następnie usługa powinna zostać zdemaskowana.

— Erik Hensema
źródło

Wykonaj poniższe kroki:

systemctl edit systemd-hostnamed

Dodaj 2 wiersze poniżej, a następnie zamknij edytor (nie zapomnij zapisać po wyświetleniu monitu):
```
[Service]
PrivateNetwork=no
```
Spowoduje to utworzenie pliku override.conf z powyższymi 2 liniami w katalogu:
```
/etc/systemd/system/systemd-hostnamed.service.d/
```
Aktualizacja systemd:
```
systemctl daemon-reload
```
Następnie uruchom ponownie usługę:
```
systemctl restart systemd-hostnamed
```

Powinieneś być teraz w stanie biegać hostnamectlbez zawieszenia.

— Hossein
źródło