Dlaczego niektóre usystematyzowane usługi są w stanie „zamaskowanym”?

42

Po uruchomieniu polecenia sudo systemctl list-unit-files(myślę, że sudo jest opcjonalne), otrzymuję dane wyjściowe, które pokazują wszystkie usługi i ich stan.

Oto fragment mojego komputera:

UNIT FILE                                  STATE
...
debian-fixup.service                       static  
debug-shell.service                        disabled
display-manager.service                    enabled 
dns-clean.service                          enabled 
dsmcad.service                             enabled 
emergency.service                          static  
failsafe-x.service                         static  
friendly-recovery.service                  masked  
fuse.service                               masked  
gdm.service                                masked  
getty-static.service                       static  
[email protected]                             enabled 
gpsd.service                               indirect
[email protected]                           static  
gpu-manager.service                        enabled 
halt-local.service                         static  
halt.service                               masked  
hostname.service                           masked
...

Zastanawiam się, dlaczego niektóre usługi są w stanie „zamaskowanym”. Myślę, że to oznacza, że ​​„jest to lepsze niż„ wyłączenie ”, ponieważ usługi nie można uruchomić ani ręcznie, ani systemd”.

Jak mogę uzyskać więcej informacji o stanie jednostki usługowej?

Kto wprowadził jednostki w odpowiedni stan?

Próbowałem na przykład sudo systemctl help dsmcad- to wyświetla tylko documentation = ...wiersz z pliku jednostkowego./etc/systemd/system/dsmcad.service

Uwaga: tutaj dokładnie wiem , czym jest usługa dsmcad i co robi, sam ją zainstalowałem. Bardziej interesuje mnie ogólne rozwiązanie.

systemd knb
źródło

Odpowiedzi:

47

maskjest silniejszą wersją disable. Korzystanie ze disablewszystkich dowiązań symbolicznych określonego pliku jednostkowego jest usuwane. Jeśli korzystasz, maskjednostki zostaną połączone z /dev/null. Zostanie wyświetlony, jeśli zaznaczysz np systemctl status halt.service. Przez . Zaletą maskjest zapobieganie jakiejkolwiek aktywacji, nawet ręcznej.

Uwaga: wyświetla systemctl list-unit-fileslistę plików jednostkowych (statyczny, włączony, wyłączony, maskowany, pośredni) i nie ma nic wspólnego ze stanem usługi. Aby zapoznać się z usługami użytku systemctl list-units.

Kellerspeicher
źródło
8
W razie potrzeby wyjaśnij również, jak usunąć stan zamaskowany.
erikbwork
19
Jest maski unmaskpoleceń, które mogą być używane z systemctl. Więc po prostu zrób systemctl unmask name_of_service.service.
Kellerspeicher
robi systemctl unmask name_of_service.servicecałkowicie usunąć mój plik z definicji usługi /etc/systemd/system/, więc teraz muszę go dodać ponownie. Jeśli znów się
zamaskuje, utknę
1
Cześć Eldamir, w /etc/systemd/systemto tylko symboliczne linki usług. Należy dodać *.serviceplik, /lib/systemd/systemz którego zostanie on połączony, /etc/systemd/systemjeśli enableusługa. masktworzy link do niego /dev/nulli unmaskusuwa go, /etc/systemd/systemi oczywiście nie ma znaczenia, czy ktoś tam umieści plik.
Kellerspeicher
3

hostname.servicejest maskowany jako nadmiarowy, ponieważ systemdustawia nazwę hosta (z / etc / hostname) bardzo wcześnie podczas uruchamiania.

To ustawienie zapewnia pakiet systemowy Debiana.

$ ls -l /lib/systemd/system/hostname.service
lrwxrwxrwx 1 root root 9 Apr  8 22:47 /lib/systemd/system/hostname.service -> /dev/null
$ dpkg-query --search /lib/systemd/system/hostname.service
systemd: /lib/systemd/system/hostname.service

Podobnie, Debian może teraz działać bez skryptu powłoki haltw systemie, zamiast tego jest obsługiwany przez systemd-shutdown ( tutaj kod źródłowy ).

Jeśli usługa została zamaskowana ręcznie, /etc/systemd/systemzamiast niej zostanie zainstalowana maska .

Usługi są również maskowane, gdy są usuwane z Debian / Ubuntu . Nie wiem dlaczego.

sourcejedi
źródło
Maskowanie vs. usuwanie usług wiąże się z różnicą usuwania i czyszczenia pakietu. W pierwszym przypadku pliki konfiguracyjne są przechowywane, dlatego błędne może być aktywowanie usługi (ponieważ plik usługi może nadal znajdować się w plikach konfiguracyjnych). Oczyszczony pakiet również usunie pliki usługi i nie będzie maskowany.
Fiximan
0

Ponieważ żądasz informacji o stanie zamaskowanym, ważne jest, aby wspomnieć, że można to zaobserwować w usłudze, która po uruchomieniu miała zmodyfikowane definicje, przeładowała (systemctl daemon-reload), a nowy stan NIE jest w porządku . Jednym łatwym przykładem do zrozumienia jest następujący scenariusz:

a) the service is running well (already started)
b) edit the service definition file and delete everything in its contents
c) reload
d) state masked will be observed too

W związku z tym stan maskowania może pochodzić z niewłaściwych definicji usług. W związku z tym użytkownik może wywołać stan zdemaskowany poprzez niewłaściwą edycję usługi.

Obserwacja: Nie jestem pewien, czy dzieje się to celowo, czy jest to zwykły błąd (opcja domyślna), ale udostępnienie ciekawych informacji może być interesujące

Thiago Conrado
źródło