В чем разница между «systemctl mask» и «systemctl disable»?

Я хочу улучшить время загрузки моего Ubuntu GNOME 16.04, отключив службы plymouth при загрузке. Я нашел два ответа о том, как это сделать на разных сайтах, а именно:

# systemctl disable plymouth-quit-wait.service 
# systemctl mask plymouth-quit-wait.service 

Я не могу выполнить ни одного из вышеперечисленных, если я не знаю, что они делают.

Если служба есть enabled, то где-то есть символическая ссылка

/etc/systemd/system

в файл модуля, чаще всего где-то в

/lib/systemd/system

Полезно, что когда вы enableработаете с сервисом, полные пути созданной ссылки и цели будут напечатаны на стандартный вывод.

Отключение службы удаляет символическую ссылку, поэтому на файл модуля это не влияет, но служба не загружается при следующей загрузке при чтении systemd /etc/systemd/system.

Однако отключенная служба может быть загружена и будет запущена, если запущена зависящая от нее служба ; enableи disableтолько настраивать поведение автозапуска для блоков, и состояние легко переопределяется.

Маскируется обслуживание один блок которого файл является символической ссылкой /dev/null. Это делает «невозможным» загрузку службы, даже если это требуется другой, включенной службой.

Когда вы maskработаете с сервисом, создается символическая ссылка из /etc/systemd/systemв /dev/null, оставляя исходный файл модуля в другом месте без изменений. Когда вы unmaskсервис, символическая ссылка удаляется.

Однако я заметил, что эти команды не всегда соблюдаются.

Когда я пытаюсь замаскировать большинство служб, происходит сбой:

$ sudo systemctl mask bluetooth.service
Failed to execute operation: Invalid argument

Конечно, я остановил службу первым. @Anwar предполагает, что маскирование возможно только для некритических сервисов.

Разоблачение маскированной службы, если только я не маскировал ее, также не выполняется (молча). Я полагаю, что это потому, что нигде нет файла модуля для службы, кроме как в виде символической ссылки /dev/null, на этот раз в /lib/systemd/system:

$ file $(locate fuse.service)
/lib/systemd/system/fuse.service: symbolic link to /dev/null
$ sudo systemctl unmask fuse.service
$ systemctl status fuse
● fuse.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

У меня не одна такая проблема

Чтобы фактически снять маску с службы x11-common, мне пришлось удалить символическую ссылку на /dev/nullи sudo apt-get install --reinstall x11-common && sudo systemctl daemon-reload. Теперь, когда я запрашиваю его, systemctl status x11-commonя вижу, что сервис имеет красивый зеленый кружок и загружен и активен (выход), хотя у него нет файла модуля.

Для дальнейшей ссылки эта статья о том, как использовать Systemctl, может оказаться полезной .

Это довольно просто.

• systemctl start, systemctl stop: запускает (останавливает) данный блок немедленно ;
• systemctl enable, systemctl disable: помечает (снимает отметки) модуль для автоматического запуска во время загрузки (в зависимости от модуля , как описано в его [Install]разделе);
• systemctl mask, systemctl unmask: запрещает (разрешает) все и любые попытки запуска рассматриваемого модуля (либо вручную, либо как зависимость от любого другого модуля, включая зависимости цели загрузки по умолчанию). Обратите внимание, что пометка для автозапуска в systemd реализована путем добавления искусственной зависимости от целевой загрузки по умолчанию к рассматриваемому модулю, поэтому «маска» также запрещает автозапуск.

Ссылка: systemctl (1) .

Подробнее: Леннарт Поэттеринг (2011-03-02). «Три уровня выключения» . systemd для администраторов . 0pointer.de.

Короче,

• disableделает устройство отключенным во время загрузки. Но это устройство может быть запущено в любое время после загрузки.

• maskотключает устройство полностью. Это не может быть начато без разоблачения. Это автоматически означает, что во время загрузки произойдет сбой.