SystemD

systemd — демон инициализации других демонов в Linux, пришедший на замену используемого ранее скрипта инициализации /sbin/init. Его особенностью является интенсивное распараллеливание запуска служб в процессе загрузки системы, что позволяет существенно ускорить старт операционной системы. Название происходит от принятого в Unix добавления суффикса «d» к демонам.

systemd — централизованная система инициализации и управления системой Linux, призванная устранить недостатки init, а также собрать множество разрозненных программ и других средств для администрирования системы в одном месте.

systemd — неизбежное зло, акт трагичного и смиренного угасания разума, грядущая эпоха идиотизма и шизофрении в стиле pulseaudio,.....

systemd — развивают Леннарт Поттеринг, Кей Сиверс и другие разработчики. Опубликован как свободное программное обеспечение под условиями лицензии GNU Lesser General Public License версии 2.1 или более поздней

http://ru.wikipedia.org/wiki/Systemd

http://www.freedesktop.org/wiki/Software/systemd/ <<----home page

http://www2.kangran.su/~nnz/pub/s4a/ <<----RU

https://wiki.debian.org/systemd <<---Debian

https://wiki.archlinux.org/index.php/Systemd <<---Arch

--------------------------------------------------- PDF--->>>------systemed.pdf

# systemctl

active (служба выполняется)

inactive (служба не была запущена)

maintenance (ремонт, обслуживание)

-------------------------------------------------------------------------

Type=oneshot

RemainAfterExit=true

Такие юниты считаются активными после завершения процесса, т. е. будет «active (exited)».

Type=oneshot

RemainAfterExit=false # это дефолт

Такие юниты считаются «starting», пока процесс работает, а потом сразу «inactive (dead)».

Остальные типы (Type!=oneshot) считаются активными, пока процесс работает (с разными уточнениями), т. е. «active (running)».

---------------------------------------------------------------------------------

=========================Команды================================

Анализ

Список запущенных юнитов:

$ systemctl

$ systemctl list-units

Список юнитов, попытка запуска которых завершилась неудачей:

$ systemctl --failed

LOAD = отображает, правильно ли было загружено, определено устройство.

ACTIVE = состояние активации юнита общее, т. е. обобщение SUB.

SUB = состояние активации юнита в частности, значения зависят от типа юнита.

Доступные файлы юнитов можно посмотреть в директориях /usr/lib/systemd/system/ и /etc/systemd/system/ (второй каталог имеет приоритет). Вы можете увидеть список установленных файлов юнитов командой:

$ systemctl list-unit-files

Использование

Юнитами могут быть, например, службы (.service), точки монтирования (.mount), устройства (.device) или сокеты (.socket).

При systemctl обычно всегда необходимо указывать полное имя файла юнита, включая суффикс, например, sshd.socket. Однако, есть несколько сокращений для указания юнита в следующих командах systemctl:

Ели вы не указали суффикс, systemctl предполагает, что это .service. Например, netcfg и netcfg.service будут трактоваться одинаково

Точки монтирования будут автоматически преобразованы в соответствующий юнит .mount. Например, указание /home равнозначно home.mount

Так же, как и точки монтирования, имена устройств автоматически преобразуются в соответствующий юнит .device, поэтому указание /dev/sda2 полностью соответствует юниту dev-sda2.device

Для получения дополнительной информации смотрите страницу справочного руководства man systemd.unit.

Незамедлительно запустить юнит:

# systemctl start юнит

Незамедлительно остановить юнит:

# systemctl stop юнит

Перезапустить юнит:

# systemctl restart юнит

Запросить у юнита перезагрузку его настроек:

# systemctl reload юнит

Показать статус юнита, а также запущен он или нет:

$ systemctl status юнит

Проверить, включен ли юнит в автозапуск при загрузке системы:

$ systemctl is-enabled юнит <-----------------------------

Включить юнит в автозапуск при загрузке системы:

# systemctl enable юнит

Убрать юнит из автозапуска при загрузке системы:

# systemctl disable юнит

Показать страницу справочного руководства, связанного с юнитом

(необходима поддержка этой функции в указанном файле юнита):

$ systemctl help юнит

Перезагрузить systemd для поиска новых или измененных юнитов:

# systemctl daemon-reload

Управление питанием

Завершить работу и перезагрузить систему:

$ systemctl reboot

Завершить работу и выключить компьютер (с отключением питания):

$ systemctl poweroff

Перевести систему в спящий режим:

$ systemctl suspend

Перевести систему в ждущий режим:

$ systemctl hibernate

Перевести систему в режим гибридного сна (или suspend-to-both):

$ systemctl hybrid-sleep

====================== Некоторые утилиты --->> ТУТ=================

systemctl - анализ и контроль состояния SystemD

journalctl - запрос содержимого SystemD -- журнал <------ https://sys-adm---journalctl

notify - может быть использован для запуска уведомления о завершении

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

cgls - иерархия контрольных групп в виде псевдографической диаграммы-дерева

cgtop - типа top

loginctl - анализ и контроль состояния login manager systemd-logind.service

nspawn - продвинутый Chroot

================================================================

# systemctl status <<----

**# systemctl cat <user@1000.service> <<<<**-----описание юнита(эфективное содержание)

After = после или с чем в зависимости запускать

Requires - зависимостити, требования

KillMode = как выключать (process-->> только главному процессу сервиса, ctlgroupe -->> всем процессам сервиса, none -->>посылать не нужно н кому, mixed -->> ..???

ExecStart = где запускать

ExecReload = где перезагружать

Type = если не пишется ...то по умолчанию -->>simple означает что процесс не "форкается"

# systemctl --type=service -->> запущенные сервисы

# systemctl start <SERVICE>.service

# systemctl enable <SERVICE>.service

# systemd-cgls

О службах и процессах

# ps

# ps xaf

# ps xawf -eopid,user,cgroup,args

# systemd-cgls

.........Многие службы используют сразу несколько рабочих процессов, и это отнюдь не всегда можно легко распознать по выводу команды ps. Встречаются еще более сложные ситуации, когда демон запускает сторонние процессы — например, веб-сервер выполняет CGI-программы, а демон cron — команды, предписанные ему в crontab. Немного помочь в решении этой проблемы может древовидная иерархия процессов, отображаемая по команде ps xaf. Именно «немного помочь», а не решить полностью. В частности, процессы, родители которых умирают раньше их самих, становят потомками PID 1 (процесса init), что сразу затрудняет процесс выяснения их происхождения. Кроме того, процесс может избавиться от связи с родителем через две последовательные операции fork (в целом, эта возможность п ризнается нужной и полезной, и является частью используемого в Unix подхода к разработке демонов). Также, не будем забывать, что процесс легко может .............

systemd предлагает простой путь для решения обсуждаемой задачи. Запуская но-

вый процесс, systemd помещает его в отдельную контрольную группу с соответствующим именем. Контрольные группы Linux предоставляют очень удобный инструментдля иерархической структуризации процессов: когда какой-либо процесс порождает потомка, этот потомок автоматически включается в ту же группу, что и родитель. При этом, что очень важно, непривилегированные процессы не могут изменить свое положение в этой иерархии. Таким образом, контрольные группы позволяют точно установить происхождение конкретного процесса, вне зависимости от того, сколько раз он форкался и переименовывал себя — имя его контрольной группы невозможно спрятать или

изменить. Кроме того, при штатном завершении родительской службы, будут заверше-

ны и все порожденные ею процессы, как бы они ни пытались сбежать. С systemd уже

невозможна ситуация, когда после остановки web-сервера, некорректно форкнувшийся

CGI-процесс продолжает исполняться вплоть до последних секунд работы системы.

В этой статье мы рассмотрим две простых команды, которые позволят вам наглядно

оценить схему взаимоотношений systemd и порожденных им процессов. Первая из этих

команд — все та же ps, однако на этот раз в ее параметры добавлено указание выводить

сведения по контрольным группам, а также другую интересную информацию:

# ps xawf -eopid,user,cgroup,args

Обратите внимание на третий столбец, показывающий имя контрольной группы, в

которую systemd поместил данный процесс. Например, процесс udev находится в группе

name=systemd:/systemd-1/sysinit.service. В эту группу входят процессы, порожден-

ные службой sysinit.service, которая запускается на ранней стадии загрузки.

Вы можете очень сильно упростить себе работу, если назначите для вышеприведен-

ной команды какой-нибудь простой и короткий псевдоним, например

alias psc=’ps xawf -eo pid,user,cgroup,args’

— теперь для получения исчерпывающей информации по процессам достаточно будет

нажать всего четыре клавиши.

Альтернативный способ получить ту же информацию — воспользоваться утилитой

systemd-cgls, входящей в комплект поставки systemd. Она отображает иерархию кон-

трольных групп в виде псевдографической диаграммы-дерева:

# systemd-cgls

......................................и т.д ---->>> ТАМ