Простите, тяпница, каберне-совиньон, всё такое...
Но нельзя отрицать, что systemd жёстко прибит к необязательным фичам ядра linux, а мэйнстримный linux софт - к systemd.
В контексте этого и моего опыта вайб-кодинга, я пристал к chatgpt с таким вопросом:
Можно ли пропатчить systemd таким образом, чтобы ему не нужны были cgroups2? цель - не повторить функциональность, а просто наделать "заглушек", чтобы программы запускались как в 1990-х.После серии наводящих промптов я получил такой ответ:
Если задача — именно обмануть systemd, а не реализовать настоящие cgroups, то можно заменить файловую систему cgroup на внутреннюю модель, хранящуюся, например, в /tmp или /run.
Например, вместо
/sys/fs/cgroup/system.slice/sshd.service/
cgroup.procs
memory.max
cpu.max
создавать
/tmp/systemd-fake-cgroup/
system.slice/
sshd.service/
procs
memory.max
cpu.max
Тогда функции вроде
cg_get_path()
cg_create()
cg_trim()
смогут работать почти без изменений, просто с другим префиксом пути.
Однако есть ограничение: ядро никогда не будет читать эти файлы. Поэтому запись в
memory.max
будет просто изменением текстового файла, без какого-либо эффекта. Если ваша цель — лишь удовлетворить ожидания systemd, этого может быть достаточно.
Проблема возникает с операциями, которые предполагают взаимодействие с ядром. Например, запись PID в cgroup.procs в реальности перемещает процесс в группу. В «фальшивой» реализации можно:
просто записывать PID в файл procs;
вести внутреннюю таблицу «unit → список PID»;
использовать её при stop и restart, отправляя сигналы этим PID.
То есть вместо
echo 1234 > cgroup.procs
получится примерно
append_pid("/tmp/systemd-fake-cgroup/system.slice/sshd.service/procs", 1234);
А при остановке сервиса:
прочитать файл procs;
проверить, какие PID ещё существуют;
отправить им SIGTERM, затем при необходимости SIGKILL;
удалить каталог.
Это уже довольно близко к поведению старых init-систем.
Есть ещё одна тонкость: некоторые части systemd ожидают событий от cgroups (например, что группа опустела после завершения всех процессов). Это тоже можно эмулировать, периодически проверяя сохранённые PID через kill(pid, 0) или анализируя /proc. Такой подход менее эффективен и не столь точен, как механизм ядра, но для минимальной совместимости может оказаться достаточным.
Вопрос: как вам такой луддизм? Закопать systemd набором патчей, позволяющим запускать прибитый к systemd софт на оффтопике, но при этом полностью уничтожающих все преимущества systemd для безопасности? Сможет ли это создать анархическое KISS движение за использование примитивных ядер там, где не нужны развесистые?
