В какой момент cgroups инициализируются для systemd?

Question

Короче говоря, я пытаюсь заставить systemd работать с установкой Arch, но без запуска systemd из init. Это означает, что я загружаюсь в систему, в которой не работает systemd, а затем пытаюсь запустить systemd на ней.

Проблема, с которой я сталкиваюсь, связана с cgroups - во время запуска systemd жалуется на отсутствие /sys /fs /cgroup /systemd как cgroup и поэтому работает с ограниченной функциональностью, так как считает, что cgroups недоступны. Это вызывает проблемы с любыми инструментами, которые используют D-Bus для связи с systemd.

При нормальной работе systemd (с идентификатором PID 1) cgroups созданы правильно, и systemd работает полностью. Однако, когда он запускается в уже загруженной системе, группы не создаются. Я хочу знать, в какой момент во время процесса инициализации /sys /fs /cgroup /systemd создается / монтируется и как я могу воспроизвести это на уже работающей системе? Я могу подтвердить, что это не / sbin / init, который создает cgroup, поскольку запуск, который вместо этого дает те же результаты.

В противном случае, где мне начать искать в исходном коде systemd? Или, может быть, есть список рассылки, где я мог бы получить лучшие ответы непосредственно от разработчиков?

Answer 1

Правильно, поэтому, немного покопавшись в исходном коде systemd , я нашел точку, в которой создается cgroup systemd. В src/core/main.c из main() вызывается функция mount_setup_early() , но только если systemd работает как PID 1, а не в контейнере. mount_setup_early() определен в src/core/mount-setup.c и просто монтирует некоторые важные файловые системы, такие как /proc , /dev и, что более важно, /sys/fs/cgroup/systemd .

Тот факт, что я пытался запустить systemd как PID!= 1 означало, что эта функция никогда не выполнялась. Итак, далее в main() test_cgroups() выполняется и завершается ошибкой, так как /sys/fs/cgroup/systemd не монтируется. Поскольку нет способа подделать PID этого процесса (или, по крайней мере, не тот, который я знаю или готов попробовать), решение состоит в том, чтобы вручную смонтировать эти файловые системы перед запуском systemd . По крайней мере, это теория.

Еще один интересный побочный эффект этого приключения - немного больше понимания того, как именованные иерархии работают с cgroups. Для cgroups доступно мало документации, особенно о том, как именно работают именованные иерархии. Чтобы смонтировать именованную иерархию аналогично тому, как это делает systemd , запустите:

mount -t cgroup cgroup -o none,name=<name> <mountpoint>

Это дает вам полностью пустую иерархию, похожую на иерархию name=systemd смонтированную в /sys/fs/cgroup/systemd . Если вы хотите связать подсистемы с этой иерархией, не заменяйте none подсистемой, которую вы хотите.

Answer 2

systemd - это система инициализации, даже если вам удастся запустить ее как PID != 1 , наверняка будет много чего не так (например, какой процесс инициализации будет отвечать за запуск / остановку процессов?)

Существуют способы использования cgroups без использования systemd , если это то, что вам нужно, поскольку они реализованы в ядре, а не в systemd , который "использует только эти возможности".

Согласно информации от разработчиков, на веб-странице systemd перечислены все виды ресурсов, включая несколько списков рассылки, URL-адрес хранилища git и документацию по проекту, которая является очень полной.