Основные процессы Linux

[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/ – удобный интструмент для создания заданий

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *