Введение в Systemd

Введение в Systemd

Systemd это относительно новый (на Enterprise Linux) системный и сервисный менеджер, однако Redhat разрабатывает его на платформе Fedora начиная с 2010 года. Он был создан разработчиками Redhat — Lennart Poettering и Kay Sievers для обеспечения контроля какие программы запускаются при загрузке системы Linux.

Что такое systemd?

Как и sysVinit, systemd это системный и сервисный менеджер который контролирует, как запускаются и останавливаются разные службы во время загрузки и выключения системы, соответственно. Так же он контролирует как сервисы (обычно службы на основе демона) добавляются в систему и затем управляются. Systemd также заменяет концепцию уровней запуска (runlevels), которая была частью sysVinit, с целями, которые вы увидите в этой статье чуть позже.

Как работает systemd?

Во-первых systemd заменяет процесс init как процесс с PID 1. это можно проверить воспользовавшись командой top:

[root@linux ~]# top -p 1 -n 1
top - 03:55:41 up 17 min, 1 user, load average: 0.01, 0.02, 0.05
Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.5 sy, 0.0 ni, 98.2 id, 0.9 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1865988 total, 1568488 free, 121016 used, 176484 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 1568864 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 125628 4200 2484 S 0.0 0.2 0:02.00 systemd

Systemd делает загрузку сервера быстрее, потому что использует меньше скриптов и пытается запускать больше задач параллельно, Systemd называет их юниты (units). В systemd сервисы задаются в так называемых юнит файлах (unit files) которые являются текстовыми файлами содержащими всю необходимую для запуска сервиса информацию, включая зависимости. Целевые юниты (target units) представляют собой уровни запуска (run levels) и сервис юниты (service units) представляют собой сервисы. Юнит файлы с расширением .target представляют собой целевые объекты загрузки, а юнит файлы с расширением .service представляют собой юниты для сервисов. Все процессы, запущенные сервисным модулем, отмечены одной и той же группой. Таким образом, когда служба отключается, упрощается обеспечение того, чтобы все связанные процессы также были отключены. Сервисные модули могут быть активированы при других событиях, таких как обнаружение оборудования, а не только при переходе на другой уровень запуска. Управление ресурсами контролируется и ограничено через группу, созданную для каждой службы. Поэтому контрольные группы предоставляют способ, с помощью которого связанные задачи или процессы могут быть агрегированы или разделены для управления. Сервис юниты запускаются параллельно. У нас могут быть зависимости между различными службами.

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

[root@linux ~]# systemd-analyze
Startup finished in 2.035s (kernel) + 2.749s (initrd) + 21.993s (userspace) = 26.778s
[root@linux ~]#

Так же мы можем узнать время необходимое для запуска каждого сервиса используя команду systemd-analyze blame:

[root@linuxnix ~]# systemd-analyze blame
5.690s NetworkManager-wait-online.service
4.774s systemd-udev-settle.service
4.165s kdump.service
3.051s tuned.service
2.877s lvm2-monitor.service
2.803s dev-mapper-clx2droot.device
2.317s polkit.service
2.053s NetworkManager.service
1.931s abrt-ccpp.service
1.560s postfix.service
---------------------output truncated for brevity

Целевые юниты Systemd

Цели в systemd коррелируют с тем, что мы называем уровнями запуска в sysVinit. Можно использовать выражения уровень запуска и цели, так как пор сути они означают одно и то же. Например, poweroff.target это эквивалент run level 0. На рисунке ниже приведено соответствие названия целей systemd уровням запуска в sysVinit.

Иллюстрация 1

При загрузке через grub мы можем по-прежнему использовать числа для загрузки на определенный уровень запуска, а также для systemd target.

Вместо того, чтобы использовать файл /etc/inittab для установки уровня запуска по умолчанию, мы можем установить его из командной строки.
Чтобы указать текущий уровень запуска по умолчанию, установленный в системе, используйте следующую команду:

[root@linux ~]# systemctl get-default
 multi-user.target
 [root@linuxnix ~]#

Цель multi-user.target соответствует run level 3 применяемом в системах с sysVinit. Это можно проверить запустив команду runlevel и узнав текущий уровень запуска:

[root@linux ~]# runlevel
N 3

Как видим, результат — run level 3.

Для изменения уровня запуска по умолчанию в системе мы можем использовать команду systemctl с подкомандой set-default и указав затем нужную цель.

[root@linux ~]# systemctl set-default multi-user.target
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/multi-user.target.
[root@linux ~]#

Для изменения текущего уровня запуска используем команду systemctl isolate и указав требуемое имя цели.
Например, чтобы изящно перезапустить систему, мы используем следующую команду:

[root@linuxnix ~]# systemctl isolate reboot.target
Connection to 192.168.188.131 closed by remote host.

Команда приведенная выше будет иметь такой же эффект как и “init 6” на операционных системах управляемых sysVinit.

Сервисные юниты Systemd

Сервисные юниты предоставляют сервисные скрипты в systemd. Команда systemctl объединяет функции, предоставляемые службами и командами chkconfig, в одну утилиту. Мы используем systemctl для включения / отключения сервисов при загрузке системы, а также для запуска, остановки, перезагрузки или перезапуске служб вручную.

Чтобы включить сервис:

systemctl enable 

На примере сервиса crond:

[root@linux ~]# systemctl enable crond

Для отключения сервиса:

systemctl disable 

На примере сервиса crond:

[root@linux ~]# systemctl disable crond
Removed symlink /etc/systemd/system/multi-user.target.wants/crond.service.

Отключение службы удалило символьную ссылку, которая обеспечила запуск службы при переходе системы на многопользовательскую цель. Включение службы восстановит символьную ссылку.

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

Остановка сервиса:

systemctl stop 

Старт сервиса:

systemctl start 

Так же можно использовать команду systemctl status для просмотра текущего статуса сервиса. На примере сервиса crond:

[root@linux ~]# systemctl status crond
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2018-01-19 04:38:35 IST; 4s ago
Main PID: 2080 (crond)
CGroup: /system.slice/crond.service
└─2080 /usr/sbin/crond -n
Jan 19 04:38:35 linuxn crond[2080]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 71% if used.)
Jan 19 04:38:35 linux systemd[1]: Started Command Scheduler.
Jan 19 04:38:35 linux crond[2080]: (CRON) INFO (running with inotify support)
Jan 19 04:38:35 linux systemd[1]: Starting Command Scheduler...
Jan 19 04:38:35 linux crond[2080]: (CRON) INFO (@reboot jobs will be run at computer's startup.)

Наряду с командой systemctl status мы можем использовать команду systemctl show для просмотра некоторых атрибутов службы. Мы продемонстрируем, используя его в службе sshd.

[root@linux ~]# systemctl show sshd
Type=forking
Restart=on-failure
PIDFile=/var/run/sshd.pid
NotifyAccess=none
RestartUSec=42s
TimeoutStartUSec=1min 30s
TimeoutStopUSec=1min 30s
WatchdogUSec=0
WatchdogTimestampMonotonic=0
StartLimitInterval=10000000
-------output truncated for brevity

Обратите внимание, что не нужно писать crond.service, чтобы команды systemctl работали. Это связано с тем, что когда мы используем команды systemctl с под-командами enable / disable / stop / start / status, это подразумевает, что мы выполняем команду в сервисном юните. Сценарии, соответствующие сервисным юнитам, находятся в каталоге /lib/systemd/system. Эти скрипты добавляются менеджером пакетов при установке приложений, которые предоставляют конкретную услугу. Мы можем вносить изменения в рабочую систему путем изменения содержимого каталога /etc/systemd/system. Когда мы изменили цель по умолчанию в нашей системе, в этом месте была создана софт ссылка.

Экосистема systemd из команд *ctl

Наряду с основным инструментом systemctl для управления целевыми и сервисными юнитами systemd предоставляет кучу других полезных утилит, о которых мы сейчас поговорим.
Команда timedatecl
Эта команда предоставляет удобный интерфейс для изменения информации о дате и часовом поясе для системы.

[root@linux ~]# timedatectl
Local time: Fri 2018-01-19 06:26:51 GMT
Universal time: Thu 2018-01-18 22:26:51 UTC
RTC time: Thu 2018-01-18 22:26:51
Time zone: Asia/Irkutsk(GMT, +0800)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
[root@linux ~]#

Команда hostnamectl
Эта команда позволяет нам постоянно изменять имя хоста системы без необходимости редактировать какие-либо файлы.

[root@linux ~]# hostnamectl
Static hostname: linux
Icon name: computer-vm
Chassis: vm
Machine ID: bca7534af004465fa35d176e2a1018c7
Boot ID: 28e151b4f42748eeba4f9575ab136743
Virtualization: vmware
Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-693.11.6.el7.x86_64
Architecture: x86-64
[root@linux ~]#

Команда localectl
Позволяет менять системный настройки локали.

[root@linux ~]# localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: us
X11 Layout: us

Команда loginctl
loginctl можно использовать для интроспекции и управления состоянием systemd login manager systemd-logind.service.

[root@linux ~]# loginctl
SESSION UID USER SEAT
2 0 root
3 0 root
2 sessions listed.

Команда journalctl
Используется для запроса содержимого журнала systemd (1), как указано в systemd-journald.service. Journalctl — это мощный инструмент для работы со всеми файлами журнала. Поскольку journald записывает журналы как двоичный файл, вам необходимо, чтобы journalctl взаимодействовал с этими журналами. Вот небольшой фрагмент команды journalctl, выполненный без каких-либо аргументов.

[root@linux ~]# journalctl
-- Logs begin at Fri 2018-01-19 03:38:26 IST, end at Fri 2018-01-19 03:57:07 IST. --
Jan 19 03:38:26 linuxnix systemd-journal[96]: Runtime journal is using 8.0M (max allowed 91.1M, trying to leave 136.6M free of 903.1M a
Jan 19 03:38:26 linuxnix kernel: Initializing cgroup subsys cpuset
Jan 19 03:38:26 linuxnix kernel: Initializing cgroup subsys cpu
Jan 19 03:38:26 linuxnix kernel: Initializing cgroup subsys cpuacct
Jan 19 03:38:26 linuxnix kernel: Linux version 3.10.0-693.11.6.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623
Jan 19 03:38:26 linuxnix kernel: Command line: BOOT_IMAGE=/vmlinuz-3.10.0-693.11.6.el7.x86_64 root=/dev/mapper/cl-root ro crashkernel=a
Jan 19 03:38:26 linuxnix kernel: Disabled fast string operations
Jan 19 03:38:26 linuxnix kernel: e820: BIOS-provided physical RAM map:

На этом всё. Надеюсь ретроградам вроде меня — так стало более понятно ;)

Рейтинг
( 2 оценки, среднее 5 из 5 )
Понравилась статья? Поделиться с друзьями:
Блог админа