[kthreadd] – PID 2, так называемый “мастер потоков” – это мастер-процесс, создающий процессы для управления аппаратной составляющей. В целом, большинство процессов ниже являются порождениями этого процесса, он как главный босс, раздающий работу и кричащий, что делать.
[rcu_gp] – Read-copy update. Специальный механизм синхронизации данных, позволяющий обрабатывать данные в несколько потоков. Нужен для многопоточной работы с данными.
[kworker/(u)X:X(H)] – процессы которые помогают ядру обрабатывать запросы. Таких процессов может быть много (в зависимости от нагрузки на ядро, чем больше запросов на выделение прерывания, чем больше таймеров и системных вызовов, тем больше процессов по работе в пространстве ядра).
[mm_percpu_wq] – процесс для управления памятью для каждого ядра.
[ksoftirqd/0] – на каждое процессорное ядро ядром Linux порождается один такой процесс, который необходим как для обработки аппаратных прерываний от установленного оборудования, прерываний от установленного программного обеспечения так и обработки исключений возникающих в процессе работы операционной системы. Посмотреть статистику можно в файле /proc/interrupts
[rcu_sched] – дополнительный процесс для корректной работы RCU (это процесс-планировщик).
[rcu_bh] – дополнительный процесс для корректной работы RCU, родственный rcu_sched, отвечает за так называемые “грейс периоды”, они же интервалы времени для завершения RCU-заданий (если простыми словами).
[migration/0] – процесс, которые распределяет другие процессы по ядрам. Один процесс на одно ядро.
[cpuhp/0] – процесс, создающийся 1 на 1 ядро, отвечающий за физическое добавление/удаление CPU в/из систем.
[kdevtmpfs] – заполняет и обслуживает дерево устройств.
[netns] – управляет сетью (фактически оно управляет пространством имен для сетей)
[khungtaskd] – процесс, который каждые две (чаще всего) минуты ищет зависшие задания.
[oom_reaper] – процесс, отвечающий за “убийство” процесса, который потребляет больше всего памяти, если ОЗУ на компьютере заканчивается.
[writeback] – процесс который записывает отложенные в кэше контроллера накопителя данные на сам накопитель. Инициировать можно командой sync
[kcompactd0] – отвечает за так называемое уплотнение памяти (работает по 1 процессу на 1 ядро, обычно – каждые 15 секунд).
[khugepaged] – отслеживает эффективность использование “huge pages” виртуальной памяти.
[crypto] – предоставляет API к крипто-модулю ядра.
[kintegrityd] – проверяет целостность блочных устройств с помощью записи/чтения с/на этих устройств/ах.
[kblockd] – процесс ищет перегрузки в I/O (операциях ввода-вывода).
[edac-poller] – ищет ошибки в памяти и устраняет их.
[devfreq_wq] – процесс разрешает повторное использование так называемых “рабочих очередей” (workqueues).
[watchdogd] – средство наблюдения за нормальной работой системы, и если происходит какой-то сбой, то данный процесс запускает сброс (reset) системы с целью возобновить нормальное функционирование.
[kswapd0] – древняя, но почтенная система управления виртуальной памятью.
[kthrotld] – контролирует пропускную способность посредством “удушения” запросов в соответствии с приоритетами.
[ipv6_addrconf] – отвечает за конфигурацию очередей IPv6.
[kworker/u2:1-events_unbound] – тот же процесс, что и kworker.
[kstrp] – так называемый “парсер потоков”, он необходим для разбора и анализа сообщений на прикладном уровне.
[ata_sff] – процесс для использования устаревших ide/pata устройств.
[scsi_eh_0] – процесс обрабатывает ошибки, которые могут появляться при подключении дисков, определяемых как scsi-устройства.
[jbd2/vda1-8] – процесс, отвечающий за обновление журнала файловой системы.
[ttm_swap] – процесс, отвечающий за использование GPU памяти.
Модули Systemd
Чтобы понять разницу между всеми этими “модулями” или “юнитами”, надо вспомнить, что systemd, как и все остальное в Linux, является файлом. И все systemd-сущности являются разными файлами (например systemd службы хранят конфигурации в файле с расширением .service, а сокеты – .socket и т.д.). Systemd, если рассматривать как демон, управляет другими демонами и является первым демоном, который запускается во время загрузки ОС.
1. Service unit (служба .service) – подразумевается самая обычная системная служба
2. Target unit (цель .target) – это юнит, используемый для группировки юнитов по зависимостям. Они выполняют ту же функцию, что и runlevels (уровни запуска), но принцип работы отличается. Посмотреть список юнитов типа “цель” можно следующей командой: systemctl list-units –type=target
3. Mount unit (точка монтирования .mount) – надстройка systemd, используемая для манипуляций точками монтирования на уровне генерации unit-файлов
4. Automount unit (точка автомонтирования .automount) – похожа на mount unit, но позволяет монтировать ФС только тогда, когда вы действительно хотите обратиться к точке монтирования, например чтобы скопировать какой-нибудь файл
5. Device unit (устройство .device) – юнит для управления девайсами, как определено в sysfs/udev (udev – утилита для управления устройствами). При запуске ОС systemd динамично создает юниты устройств для всех кернел-девайсов, которые помечены udev-тегом “systemd” – к ним чаще всего относятся блочные и сетевые устройства, и некоторые другие. Посмотреть список юнитов можно как и остальные: systemctl list-units –type=device
6. Path unit (файловый путь .path) – используется для наблюдения за файлом или директорий на предмет наличия определенного события, и если это событие происходит, то выполняется запуск service-юнита с таким же именем (если не указан другой). Тут стоит привести более конкретный пример, чтобы было понятнее:
Например есть такой юнит:
[Unit]
Description=Smotrim za izmeneniyami v faile
[Path]
PathChanged=/home/some_path/some_file
Unit=changes_applied.service
[Install]
WantedBy=multi-user.targetОн описывает следующее:
Вы наблюдаете за файлом /home/some_path/some_file, и если он меняется, то запускается сервис, определенный в Unit=changes_applied.service.
7. Scope unit (не создаются через конфигурационные файлы, только программно через bus-интерфейсы systemd, имеют расширение .scope) – если говорить просто и коротко – нужен для создания контрольных групп (cgroups) для дерева процессов.
8. Slice unit (слайс имеет расширение .slice) – это юнит, использующий концепт ограниченного потребления ресурсов группой процессов. Тесно связан с cgroups. Юниты, управляющие процессами (обычно это .service и .scope юниты), могут быть назначены конкретному слайсу. И этому слайсу могут быть назначены лимиты потребления ресурсов для всех процессов всех юнитов, собранном в этом слайсе.
9. Snapshot unit (снимок .snapshot) – не конфигурируется через файл. Сам файл.snapshot ссылается на конкретный снимок systemd-состояния. Снимок создается динамично через systemctl snapshot. Снимок работает как сохраненное состояния systemd менеджера.
10. Socket unit (гнездо, сокет с расширением .socket) – обычный сокет, только в виде systemd-юнита. Для каждого сокет-юнита должен быть создан service-юнит, работающий с данным сокетом. Самый обычный сокет выглядит так:
a. [Unit] Description = Socket for echoing
b. [Socket] ListenStream = 1111
c. Accept = yes
d. [Install] WantedBy = sockets.target
e. Юнит будет слушать 1111 порт, вы также можете указать и полный IP-адреc.
11. Swap unit (файл подкачки или раздел подкачки .swap) – управляет swap-файлами/разделами.
12. Timer unit (таймер .timer) – юнит, позволяющий контролировать сервисы или события, можно назвать его аналогом крона. Имеет поддержку календарных и регулярных событий. Бывают таймеры реального времени (OnCalendar= …) и монотонные таймеры (OnTypeSec= …), где Type – тип события (загрузка OnBootSec, активация юнита OnUnitActiveSec и т.д.)
systemctl – основной инструмент управления systemd.
Синтаксис:
Запуск, останов и просмотр статуса какой-либо службы происходит посредством команд:
Примечание: в debian 10 команда без d, просто
cron
systemctl start crond
systemctl stop crond
systemctl status crond
Перезапуск командой
systemctl restart crond
Для добавления сервиса в автозагрузку используется
systemctl enable crond
Чтобы убрать приложение из автозапуска, соответственно
systemctl disable crond
Можно также “замаскировать” сервис – то есть, лишить модуль возможности запускаться.
systemctl mask crond
Посмотреть дерево зависимостей – от каких процессов зависит cron.
systemctl list-dependencies crondСписок всех имеющихся модулей в системе покажет команда systemctl list-units
Рассмотрим отдельно модуль файла планировщика cron
[Unit] – директива, указывающая systemd, что эта часть файла является описательной, указывает параметры запуска и т.д.
Description=Regular background program processing daemon – описание юнита
Documentation=man:cron(8) – указание пути к документации
After=remote-fs.target nss-user-lookup.target – параметр, указывающий, что данный юнит должен запускаться после (after) модуля, указанного справа от “=”.
[Service] – блок конфигурации юнита
EnvironmentFile=/etc/default/cron – файл окружения
ExecStart=/usr/sbin/cron -f $EXTRA_OPTS – команда для старта
IgnoreSIGPIPE=false – параметр для игнорирования SIGPIPE сигнала (SIGPIPE — сигнал, посылаемый процессу при записи в соединение (пайп, сокет) при отсутствии или обрыве соединения с другой (читающей) стороной.)
KillMode=process – указывает, как “убивать” процесс.
Restart=on-failure – указание, когда необходимо перезагружать сервис.
[Install] – блок, описывающий информацию об установке юнита (нужен для команд systemctl enable/disable)
WantedBy=multi-user.target – данная директива, является наиболее распространенным способом определения того, как юнит должен быть включен, от чего зависит.
Cинтаксис планировщика Крон:
минута, час, день месяца, месяц, день недели (0 = воскресенье)
запускаемая команда
https://crontab.guru/ – удобный интструмент для создания заданий
