Я хотел бы использовать journald в контейнере без systemd. Это возможно? Если да, то как это сделать? О каких проблемах нужно позаботиться?
Journald - неотъемлемый компонент пакета Systemd. Из systemd для администраторов, XVII:
Если вам интересно, что такое журнал, вот краткое объяснение, которое поможет вам быстрее освоиться: журнал является компонентом systemd, который фиксирует сообщения системного журнала, сообщения журнала ядра, сообщения начального RAM-диска и ранней загрузки, а также сообщения, записанные в STDOUT / STDERR всех служб, индексирует их и делает доступными для пользователя. Его можно использовать параллельно или вместо традиционного демона syslog, такого как rsyslog или syslog-ng.
Как systemd обрабатывает контейнеры, описано в Новые интерфейсы группы управления, например
systemd через свою концепцию «единицы» уже реализует сеть зависимостей между объектами, где может происходить распространение, и содержит мощную очередь выполнения. Кроме того, большая часть ресурсов объектов, для которых необходимо контролировать, уже являются объектами systemd, в первую очередь сервисами, которыми управляет systemd.
Почему это не управляется компонентом, независимым от systemd?
Что ж, как упоминалось выше, сеть зависимостей между объектами, которую можно использовать для распространения, в сочетании с мощным механизмом выполнения - это в основном то, что такое systemd. Поскольку управление cgroups требует именно этого, очевидный выбор - просто реализовать это в самом systemd.
Реализация аналогичной сети распространения / зависимости с планировщиком выполнения вне systemd в независимом демоне «cgroup» в основном означала бы повторную реализацию systemd во второй раз. Кроме того, доступ к такой внешней службе из PID 1 для управления другими службами приведет к циклическим зависимостям между PID 1, которым потребуется эта функциональность для управления службой cgroup, которая будет доступна только после того, как эта служба завершит запуск. Такие циклические зависимости, безусловно, можно обойти, но они усложняют такую конструкцию.
Такая структура была критиковали против философии UNIX:
"Systemd бросает вызов философии Unix:" делай одно дело и делай это хорошо ", представляя собой сложную коллекцию из десятков тесно связанных двоичных файлов1. Его обязанности значительно превышают обязанности системы инициализации, поскольку она продолжает управлять питанием , управление устройством, точки монтирования, cron, шифрование диска, API сокетов / inetd, системный журнал, конфигурация сети, управление входом / сеансом, упреждающее чтение, обнаружение разделов GPT, регистрация контейнера, управление именем хоста / локали / времени и другие вещи. Будьте проще , тупой."