Чому деякі системні служби перебувають у "маскованому" стані?

42

Коли я запускаю команду sudo systemctl list-unit-files(я думаю, що судо не є обов'язковим), я отримую висновок, який показує всі сервіси та їх стан.

Ось фрагмент з моєї машини:

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  
getty@.service                             enabled 
gpsd.service                               indirect
gpsdctl@.service                           static  
gpu-manager.service                        enabled 
halt-local.service                         static  
halt.service                               masked  
hostname.service                           masked
...

Цікаво, чому деякі служби перебувають у "маскованому" стані. Я думаю, що це означає, що "це краще, ніж" відключити ", тому що послугу неможливо запустити ні вручну, ні системою".

Як я можу отримати більше інформації про стан сервісного підрозділу?

Хто перевів підрозділи у відповідний штат?

Я спробував, наприклад, sudo systemctl help dsmcad- що відображає лише documentation = ...рядок з файлу одиниці./etc/systemd/system/dsmcad.service

Примітка. Тут я точно знаю , що таке служба dsmcad і що вона робить, я її встановив сам. Мене більше цікавить загальне рішення.

systemd

— кнб
джерело

47

maskє сильнішою версією disable. Використовуючи disableвсі посилання вказаного файлу одиниць, видаляються. Якщо за maskдопомогою одиниць буде пов'язано /dev/null. Це відобразиться, якщо ви позначете, наприклад, від systemctl status halt.service. Перевагою maskє запобігання будь-якого виду активації, навіть ручного.

Застереження: systemctl list-unit-filesперераховує стан файлів одиниць (статичні, увімкнені, відключені, масковані, непрямі) і не має нічого спільного зі станом служби. Щоб ознайомитися з використанням послугsystemctl list-units .

— Kellerspeicher
джерело

8

Будь ласка, поясніть, як зняти замаскований стан, якщо потрібно.

— erikbwork

19

Існує maskі unmaskкоманда , яка може бути використана з systemctl. Так просто робіть systemctl unmask name_of_service.service.

— Kellerspeicher

я systemctl unmask name_of_service.serviceповністю видалив файл мого визначення служби /etc/systemd/system/, тому тепер мені потрібно знову додати його. Якщо він знову стане маскуватися, я застрягну в петлі

— oO

1

Привіт, Ельдаміре, у цьому тексті /etc/systemd/systemє лише символічні посилання сервісів. Вам слід додати *.serviceфайл до місця, /lib/systemd/systemз яким він буде пов’язаний, /etc/systemd/systemякщо ви enableпослуга. maskстворює посилання на /dev/nullі unmaskвидаляє це посилання, /etc/systemd/systemі, очевидно, це не має ніякого значення, якщо хтось покладе файл туди.

— Kellerspeicher

3

hostname.serviceмаскується як надмірне, оскільки systemdвстановлює ім'я хоста (від / etc / hostname) дуже рано під час запуску.

Цей параметр надається системним пакетом Debian.

$ 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

Точно так само Debian тепер може працювати без скрипта оболонки до haltсистеми, вона обробляється замість systemd-shutdown (вихідний код тут ).

Якщо послугу замаскували вручну, /etc/systemd/systemзамість неї буде встановлена маска .

Послуги також маскуються, коли вони видаляються на Debian / Ubuntu . Я не знаю чому.

— sourcejedi
джерело

Маскування та видалення послуг має різницю між видаленням та очищенням пакета. У першому випадку конфігураційні файли зберігаються, і, отже, може бути небезпечно помилково активувати послугу (оскільки сервісний файл все ще може бути у конфігураційних файлах). Очищений пакет також видалить службові файли та не буде маскуватися.

— Фіксиман

0

Оскільки ви запитуєте інформацію про стан маскування, важливо згадати, що його можна спостерігати в сервісі, який після запуску змінив його визначення, перезавантажив (systemctl daemon-reload) і новий стан НЕ нормально . Одним із простих прикладів для розуміння цього є такий сценарій:

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

Отже, масковане стан може походити з неправильних визначень служби. Отже, користувач може викликати нерозкритий стан, неправильно відредагувавши послугу.

Спостереження: я не впевнений, чи трапляється це спеціально або це проста помилка (параметр за замовчуванням), але можливо поділитися цікавою інформацією

— Тіаго Конрадо
джерело