Vendor preset disabled что означает

35. Системный менеджер systemd

Как мы разобрались в прошлый раз, при запуске компьютера система инициализации запускает всякие сервисы, которые работают в фоне. По большей части работа системного администратора заключается в том, чтобы следить за состоянием операционной системы, устанавливать и настраивать всякие сервисы. На серверах крутятся всякие сервисы, допустим, тот же веб сервер, где крутятся сайты.

systemd, как сервисный менеджер, позволяет управлять этими сервисами. Для примера возьмём сервис под названием sshd. Вы часто будете встречать сервисы с буквой d в конце — она означает daemon, то есть демон программы ssh. Базовые операции — это остановить, запустить и перезапустить сервис — то есть:

sudo systemctl stop sshd sudo systemctl start sshd sudo systemctl restart sshd 

соответственно. Как понятно из названия, restart останавливает и запускает сервис заново. Обычно перезапускают сервис, когда изменяются какие-то настройки демона. Нужно его заново запустить, чтобы он перечитал свои настройки. Для каких-то сервисов это не проблема, но бывают важные сервисы, в которых даже секундная остановка вызывает проблемы. Для таких сервисов существует возможность перезапустить основной демон, при этом не затронув текущие процессы. Для этого используется опция reload:

sudo systemctl reload sshd 

systemctl enable sshd 

даёт возможность запускать сервис автоматом при включении компьютера. Мы можем сделать

systemctl disable sshd 

если не хотим, чтобы сервис стартовал при включении. И тем не менее, другие программы и пользователи могут запустить этот сервис при необходимости. Если же мы хотим, чтобы этот сервис нельзя было запустить, мы можем его замаскировать, с помощью команды:

systemctl mask sshd 

Как видите, создаётся символическая ссылка, ведущая на /dev/null — то есть, при попытке запустить сервис ничего не произойдёт. Но это касается только сервиса, если мы вручную запустим программу, она будет работать. Ну и с помощью unmask:

sudo systemctl unmask sshd 

мы можем сервис размаскировать.

Также мы можем посмотреть статус этого сервиса с помощью команды status:

systemctl status sshd 

В строчке Loaded мы видим путь до основного файла сервиса. Дальше 2 раза видим слово enabled. Первый enabled говорит о том, что сервис включён, т.е., он будет запускаться при включении компьютера. Перед вторым enabled написано vendor preset. То есть, имеется в виду, что этот сервис был включён по умолчанию ещё при установке программы или операционной системы.

В строчке Active мы видим, что сервис работает. Если остановить сервис, здесь будет писаться inactive.

Иногда, вместо active (running), можно увидеть active (exited):

systemctl status vboxadd 

Собственно, ничего страшного в этом нет. Если это какой-то демон, который постоянно работает на фоне, systemd может отслеживать состояние процесса и говорить, что он работает, то есть running. Но иногда вместо полноценного демона за сервисом стоит какой-то скрипт, который запускается, выполняет свою работу, запускает какие-то программы и завершается. И вроде скрипт больше не работает, но свою работу он сделал. Поэтому так и выходит — вроде это и не демон, отслеживать нечего, но при этом то что нужно работает.

Вернёмся к нашему sshd. Дальше у нас ссылки на документацию и PID основного процесса, который запустился при старте сервиса. Дальше Tasks — общее количество процессов — включая основной и его дочерние. Memory — сколько оперативки использует этот сервис. Дальше CGroup — контрольная группа, в которую входят процессы этого сервиса. С помощью контрольных групп на уровне ядра можно изолировать группу процессов и выделять им ограниченные ресурсы — сколько-то оперативки, сколько-то процессора и т.п. Эдакая виртуализация на уровне самой операционной системы. Чуть ниже в статусе мы видим логи. К ним мы ещё вернёмся.

Я не хочу ударяться в объяснение каждой из команд systemctl, типа systemctl cat sshd, show, edit и всё такое. Не все команды используются часто, многие специфичны. На что-то мы наткнёмся и разберём, что-то вы по работе разберёте, а с чем-то и в вовсе не столкнётесь.

Как мы упомянули в прошлый раз, systemd отвечает не только за сервисы. Если запустить команду:

systemctl --all 

мы увидим информацию о всех unit-ах — а тут и сервисы, и таргеты, и устройства, и mount-ы, и всякое другое. С сервисами и таргетами мы разобрались, немного поговорим про другие юниты.

Помните, когда мы говорили про ядро, мы упомянули udev? Программа, которая делает какие-то действия при виде устройств — даёт названия устройствам, создаёт ссылки в директории /dev, может передать ядру какие-то параметры для устройства, запустить какие-то программы и т.п. Так вот, udev — тоже демон, но, к тому же, он является частью systemd, генерирует юнит файлы для устройств, называемые device unit-ами. Это позволяет сделать связь между устройствами и другими сервисами.

Или, допустим, mount unit-ы. Для примера возьмём mydata.mount:

systemctl show mydata.unit 

При включении компьютера кто-то же должен примонтировать все файловые системы, указанные в fstab? Так вот, systemd генерирует специальные unit-ы на основе записей fstab и монтирует их. При этом он смотрит зависимости, скажем, отличает локальные файловые системы от сетевых и на основе этого формирует зависимости при создании юнитов. Есть ещё swap unit-ы — примерно тоже самое, но для swap разделов.

Про остальные unit-ы мы поговорим, когда будем разбирать темы, связанные с ними. А сегодня мы разобрали как работать с сервисами, как смотреть информацию о них, и в целом стали лучше понимать, чем же занимается systemd.

© Авторские права 2021, GNU Linux Pro, CC-BY-SA-4.0. Ревизия b16e73a6 .

systemd Часть 2: Управление юнитами, зависимостями и целями

В этой статье разберем управление юнитами, зависимостями и целями.

Управление юнитами через systemd

Для управления юнитами используется команда systemctl .

Вот как это делается?

Для примера установим пакет php-fpm :

[root@server2]# yum install -y php-fpm.x86_64

Запускаем сервис php-fpm.service :

systemctl start php-fpm

Как я узнал, что сервис называется именно так и что вообще при установке пакета создался и сервис?

В первой части статьи было сказано:

/usr/lib/systemd/system
Системные юнит-файлы. Это юниты из установленных пакетов RPM — всякие nginx, apache, mysql и прочее.

Поэтому вводим и получаем:

[root@server2 system]# ls -l /usr/lib/systemd/system | grep php -rw-r--r--. 1 root root 314 Oct 31 2018 php-fpm.service

Значит юнит-файл service уже создан пакетом:

[root@server2 system]# systemctl status php-fpm.service ● php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled) Active: inactive (dead)

Запускаем:

[root@server2 system]# systemctl start php-fpm.service

Снова смотрим статус:

● php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2019-08-15 14:19:59 +10; 46s ago Main PID: 14058 (php-fpm) Status: "Processes active: 0, idle: 5, Requests: 0, slow: 0, Traffic: 0req/sec" CGroup: /system.slice/php-fpm.service ├─14058 php-fpm: master process (/etc/php-fpm.conf) ├─14059 php-fpm: pool www ├─14060 php-fpm: pool www ├─14061 php-fpm: pool www ├─14062 php-fpm: pool www └─14063 php-fpm: pool www Aug 15 14:19:59 server2 systemd[1]: Starting The PHP FastCGI Process Manager. Aug 15 14:19:59 server2 systemd[1]: Started The PHP FastCGI Process Manager.

Сервис успешно запущен. Но чтобы он всегда запускался при загрузке системы, поставим его в автозагрузку.

[root@server2 system]# systemctl enable php-fpm.service Created symlink from /etc/systemd/system/multi-user.target.wants/php-fpm.service to /usr/lib/systemd/system/php-fpm.service.

Используя команду systemctl status вы можете увидеть такие состояния:

Также часто необходимо получать обзор текущего состояния юнит-файлов в systemd .

Управление зависимостями

Юниты systemctl во многих случаях имеют зависимости. Некоторые юниты будут запускаться как зависимость от других юнитов, и событие, когда запрашивается один конкретный юнит, может вызвать запуск другого юнита.

Примером является сервис cups.service . Эта служба может быть запущена сама по себе, но она также может быть запущена на юнитах cups.path и cups.socket , что может привести к повторному запуску службы.

На примере всё того же php-fpm посмотрим список зависимостей:
Так как список большой, то отобразил только несколько строк.

[root@server2 system]# systemctl list-dependencies php-fpm php-fpm.service ● ├─-.mount ● ├─system.slice ● └─basic.target ● ├─microcode.service ● ├─rhel-dmesg.service ● ├─selinux-policy-migrate-local-changes@targeted.service ● ├─paths.target ● ├─slices.target ● │ ├─-.slice ● │ └─system.slice ● ├─sockets.target ● │ ├─dbus.socket ● │ ├─dm-event.socket ● │ ├─rpcbind.socket ● │ ├─systemd-initctl.socket ● │ ├─systemd-journald.socket ● │ ├─systemd-shutdownd.socket ● │ ├─systemd-udevd-control.socket ● │ └─systemd-udevd-kernel.socket ● ├─sysinit.target ● │ ├─dev-hugepages.mount ● │ ├─dev-mqueue.mount ● │ ├─kmod-static-nodes.service ● │ ├─lvm2-lvmetad.socket ● │ ├─lvm2-lvmpolld.socket ● │ ├─lvm2-monitor.service ● │ ├─plymouth-read-write.service ● │ ├─plymouth-start.service ● │ ├─proc-sys-fs-binfmt_misc.automount ● │ ├─rhel-autorelabel.service 

Введите systemctl list-dependencies , за которым следует имя юнита, чтобы узнать, какие у него есть зависимости, и добавьте параметр —reverse , чтобы узнать, какие юниты зависят от этого юнита.

[root@server2 system]# systemctl list-dependencies --reverse sshd sshd.service ● └─multi-user.target ● └─graphical.target

Кроме зависимостей, некоторые юниты могут конфликтовать с другими юнитами.

• mount и umount юниты не могут быть загружены совместно;
• ifconfig и NetworkManager сервис;
• iptables и firewalld ;
• cronyd и ntpd .

Другой способ, чтобы быть уверенным, что конфликтующие юниты никогда не будут загружены одновременно в одной и той же системе это использовать команду systemctl mask .service . Когда вы выполните команду, то запуск юнита переадресуется символьной ссылкой на /dev/null и юнит больше никогда не запустится.

Чтобы отменить это, выполните systemctl umask .service .

Изолирующие цели

Как уже обсуждалось, в systemd есть несколько целей. Вы также знаете, что цель — это набор юнитов. Некоторые из этих целей играют особую роль, потому что они могут быть изолированы. Выделив цель, вы запускаете эту цель со всеми ее зависимостями. Не все цели могут быть изолированы, но только цели, у которых включена опция изоляции. Мы рассмотрим команду systemctl isolate в ближайшее время. Прежде чем сделать это, давайте посмотрим на цели по умолчанию.

Чтобы посмотреть все загруженные цели, введем:

[root@server2 ~]# systemctl --type=target UNIT LOAD ACTIVE SUB DESCRIPTION basic.target loaded active active Basic System cryptsetup.target loaded active active Local Encrypted Volumes getty.target loaded active active Login Prompts local-fs-pre.target loaded active active Local File Systems (Pre) local-fs.target loaded active active Local File Systems multi-user.target loaded active active Multi-User System network-online.target loaded active active Network is Online network-pre.target loaded active active Network (Pre) network.target loaded active active Network nfs-client.target loaded active active NFS client services nss-user-lookup.target loaded active active User and Group Name Lookups paths.target loaded active active Paths remote-fs-pre.target loaded active active Remote File Systems (Pre) remote-fs.target loaded active active Remote File Systems rpc_pipefs.target loaded active active rpc_pipefs.target rpcbind.target loaded active active RPC Port Mapper slices.target loaded active active Slices sockets.target loaded active active Sockets swap.target loaded active active Swap sysinit.target loaded active active System Initialization timers.target loaded active active Timers LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 21 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.

Некоторые из целей в системе играют важную роль, поскольку их можно запускать (изолировать) для определения уровня запуска системы и которые можно установить в качестве цели по умолчанию.

• poweroff.target — уровень запуска 0
• rescue.target — уровень запуска 1
• multi-user.target — уровень запуска 3
• graphical.target — уровень запуска 5
• reboot.target — уровень запуска 6

Переходим в /usr/lib/systemd/system , вводим grep Isolate *.target :

[root@server2 ~]# cd /usr/lib/systemd/system [root@server2 system]# grep Isolate *.target ctrl-alt-del.target:AllowIsolate=yes default.target:AllowIsolate=yes emergency.target:AllowIsolate=yes graphical.target:AllowIsolate=yes halt.target:AllowIsolate=yes initrd-switch-root.target:AllowIsolate=yes initrd.target:AllowIsolate=yes kexec.target:AllowIsolate=yes multi-user.target:AllowIsolate=yes poweroff.target:AllowIsolate=yes reboot.target:AllowIsolate=yes rescue.target:AllowIsolate=yes runlevel0.target:AllowIsolate=yes runlevel1.target:AllowIsolate=yes runlevel2.target:AllowIsolate=yes runlevel3.target:AllowIsolate=yes runlevel4.target:AllowIsolate=yes runlevel5.target:AllowIsolate=yes runlevel6.target:AllowIsolate=yes system-update.target:AllowIsolate=yes

Видим список изолированных целей. Далее изолируем цель systemctl isolate rescue.target и тем самым запустим систему в режиме восстановления.

Система перейдет в режим восстановления:

Sysadminium

В этой статье мы подробнее посмотрим на юниты SystemD с типом Service. Разберём параметры из юнита ssh.service и не только.

Оглавление скрыть

Юниты SystemD типа service

В SystemD все сервисы которые можно запускать или останавливать описываются в специальных юнитах service. Это значит, что в таких юнитах описывается вся информация, которая поможет запустить сервис (службу).

Наверно юниты SystemD следовало изучать после изучения процессов. И скорее всего в будущем я поменяю очерёдность в оглавлении. Но сейчас я постарался описать службы (юниты типа service) с минимальным объяснением процессов.

Как вам известно, юниты — это обычные файлы. В юнитах типа service описывается способ запуска исполняемых файлов (бинарных или скриптов).

В SystemD есть специальная утилита, которая позволяет управлять службами — systemctl. Вот некоторые её подкоманды:

• systemctl start — запуск службы. При этом происходит какая-то подготовка и запуск одного или нескольких исполняемых файлов. А когда запускаются исполняемые файлы, то в системе стартуют соответствующие процессы. Из этого следует, что после запуска службы в системе запустится один или несколько процессов, которые будут работать в одной службе.
• systemctl stop — остановка службы. Эта команда должна остановить службу. При этом должны остановиться все связанные со службой процессы. Хотя процессы не обязательно должны завершиться, это зависит от того, что написано в юните.
• systemctl status — статус службы. С помощью этой команды можно узнать статус службы. А именно запущена ли она или нет, какие в неё работают процессы и какой из них главный процесс. А также можно посмотреть последние логи службы.
• systemctl reload — перечитывание конфигурации. Эта команда заставит работающие процессы перечитать свои конфиги. Хотя на самом деле, она выполнит то, что написано в юните.
• systemctl restart — перезапуск службы. То есть остановка и последующее включение службы.
• systemctl enable — включение автозапуска. Эта команда включает автозапуск для службы, а вот когда будет срабатывать автозапуск, зависит от написанного в юните.
• systemctl disable — выключение автозапуска. А эта команда выключает автозапуск у службы.
• systemctl cat — вывод содержимого файла юнита. То есть делает тоже самое, что и команда cat /путь/unit.service.

alex@deb:~$ sudo systemctl status ssh ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-07-21 13:59:59 MSK; 5min ago Docs: man:sshd(8) man:sshd_config(5) Process: 10614 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) Main PID: 10615 (sshd) Tasks: 1 (limit: 2340) Memory: 1.1M CPU: 76ms CGroup: /system.slice/ssh.service └─10615 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

alex@s-deb:~$ cat /lib/systemd/system/ssh.service *** Этот вывод я пропущу, так как он аналогичен выводу следующей команды *** alex@s-deb:~$ systemctl cat ssh.service # /lib/systemd/system/ssh.service [Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755 [Install] WantedBy=multi-user.target Alias=sshd.service