В какой момент cgroups инициализируются для systemd?
Короче говоря, я пытаюсь заставить 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? Или, может быть, есть список рассылки, где я мог бы получить лучшие ответы непосредственно от разработчиков?
2 ответа
Правильно, так что после того, как немного покопаться в исходном коде systemdЯ нашел точку, в которой создается systemd cgroup. В 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 с подсистемами, которые вы хотите.
systemd система инициализации, даже если вам удастся запустить ее как PID != 1, наверняка будет много чего не так (например, какой процесс инициализации будет отвечать за запуск / остановку процессов?)
Есть способы использования cgroups без использования systemd, если это то, что вам нужно, так как они реализованы в ядре, а не в systemd, который "только", используя эти возможности.
Согласно информации от разработчиков, на веб-странице systemd перечислены все виды ресурсов, включая несколько списков рассылки, URL-адрес хранилища git и документацию по проекту, которая является очень полной.