systemctl, come smascherare

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

Ci ho provato systemctl unmask x11-commone systemctl unmask x11-common.servicequesto non ha cambiato nulla.

Come posso smascherarlo?

systemd

— Albert
fonte

I comandi che stai utilizzando sono entrambi corretti . Vedi anche il manuale .

Sembra che il unmaskcomando fallisca quando non ci sono file di unità esistenti nel sistema oltre al collegamento simbolico a /dev/null. Se sei maskun servizio, questo crea un nuovo link simbolico /dev/nullin /etc/systemd/systemcui systemd cerca i file di unità da caricare all'avvio. In questo caso, non esiste un file di unità reale.

Altri sembrano avere problemi simili

x11-common.serviceè stato anche mascherato sul mio sistema. Puoi sistemarlo in questo modo:

Verificare innanzitutto che il file di unità sia un collegamento simbolico a /dev/null

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

dovrebbe restituire:

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

nel qual caso, eliminalo

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

Poiché hai modificato un file di unità, devi eseguire questo:

sudo systemctl daemon-reload

ora controlla lo stato:

systemctl status x11-common

se non dice caricato e in esecuzione (se il cerchio è ancora rosso), reinstallare il pacchetto:

sudo apt-get install --reinstall x11-common

e ricaricare nuovamente il demone

sudo systemctl daemon-reload

e controlla ancora una volta lo stato

systemctl status x11-common

Ora è verde e funzionante :) Il servizio non ha file di unità di systemd, ma systemd usa felicemente lo script per esso /etc/init.d.

— Zanna
fonte

Ok, domanda di follow-up: se è stato persino mascherato sul tuo sistema, a cosa serve questo servizio? Sembra che non sia realmente necessario se è mascherato per entrambi.

— Albert,

@Albert [Vedi qui.] ( Askubuntu.com/questions/712276/… ) sembra che il servizio funzioni senza il file di unità systemd (ha un file in /etc/init/...). Potresti voler fare una nuova domanda. Quello che ho fatto non ha fatto alcuna differenza apparente, solo il servizio mostra come caricato, abilitato, arrestato (è attivo all'avvio) (verde) invece di carico mascherato morto (rosso). Dovrei leggere i miei registri ...

— Zanna,

se arriva un aggiornamento per systemd, il file dell'unità viene reinstallato, quindi questa non è davvero una soluzione strutturale

— hbogert

@hbogert succede anche se non ci sono file unit a parte il link simbolico a /dev/null? Hai ragione sulla mia risposta però. Definirei questa soluzione una soluzione alternativa per un ... comportamento confuso ... di systemd

— Zanna,

Potresti descrivere la tua prima frase in termini di file esatti che contano in questo caso (perché non capisco davvero lo scenario che descrivi)?

— hbogert,

Potrebbe essere che il tuo servizio abbia un file di sostituzione vuoto, come questo:

● redis-server.service - Archivio valori-chiave avanzato Caricato: caricato (/lib/systemd/system/redis-server.service; mascherato; preimpostazione fornitore: abilitato) Drop-In: / etc / systemd / system / redis-server .service.d └─limit.conf

Controlla se limit.conf è un file vuoto. Se lo è, rimuovilo. Quindi il servizio dovrebbe essere smascherato.

— Erik Hensema
fonte

Seguire i passaggi seguenti:

systemctl edit systemd-hostnamed

Aggiungi le 2 righe seguenti, quindi esci dall'editor (non dimenticare di salvare quando richiesto):
```
[Service]
PrivateNetwork=no
```
Questo creerà un file override.conf con le 2 righe sopra nella directory:
```
/etc/systemd/system/systemd-hostnamed.service.d/
```
L'aggiornamento systemd:
```
systemctl daemon-reload
```
Quindi riavviare il servizio:
```
systemctl restart systemd-hostnamed
```

Ora dovresti essere in grado di correre hostnamectlsenza che si blocchi.

— Hossein
fonte