Проблема обсуждалась здесь :https://bugs.archlinux.org/task/61964
Это было введено оптимизацией для eDP 1.4+ («быстрая и узкая конфигурация ссылок» )в ядре 5.x; патч не работает для некоторых панелей, в том числе для XPS 15, и его пришлось откатить.
Откат был объединен и должен быть выпущен со следующей версией ядра (5.0.8):
https://github.com/torvalds/linux/commit/21635d7311734d2d1b177f8a95e2f9386174b76d
Это всегда было возможно.
Чтобы сделатьinit
(процесс 1 ), станьте родительским процессом. Все, что вам нужно сделать, это раскошелиться и умереть. Если родительский процесс умирает, то init
усыновляет дочерний процесс-сироту.
Другой частью демонетизации является закрытие stdin/stdout/stderr или, по крайней мере, отключение от терминала.
Ничто из этого не меняет владельца процесса. Это может сделать только процесс с полномочиями CAP _SETUID (root ). Если позволить владельцу процесса измениться, сделав его осиротевшим, то безопасность станет бесполезной.
А почему. Я не знаю.
Фундаментальный механизм так же стар, как fork
+ wait
сами по себе, конечно. Удобные инструменты командной строки -для выполнения подобных задач существуют с 1990-х годов. Он никак не начинался с systemd.
Известный пакет daemontools Дэниела Дж. Бернштейна мог использоваться без прав суперпользователя пользователями, которые хотели управлять своими наборами сервисов. Пользователь вполне может настроить каталог сканирования и запустить svscan
для него. Единственная отсутствующая часть, которая просто должна быть написана администратором, — это инфраструктура для автоматического запуска svscan
для пользователей, которая, конечно же, является просто системной службой, которая сбрасывает привилегии и запускает svscan
от имени соответствующего пользователя.
То же самое верно для всех других наборов инструментов семейства daemontools, от s6 Лорана Беркота до perp Уэйна Маршалла.
Наборы инструментов управления службами, которые предоставляли такую инфраструктуру «из коробки», вместо того, чтобы ожидать, что системный администратор настроит такие службы вручную с нуля, в основном начинались с Upstart, чья init
программа имела режим «инициализации сеанса», который не 't вполне на -пользователя.
агенты запуска в MacOS представляют собой аналогичную идею, хотя launchd
тесно связаны с Mach.
Systemd появился позже. Он может работать в пользовательском -режиме, при этом общесистемный -диспетчер служб создает экземпляр сервисной единицы шаблона для каждого пользователя по запросу (с помощью довольно сложной комбинации надстроек PAM -, рабочего стола. Автобус,и демон «входа» ), который запускает другой экземпляр программы systemd
.
Другие наборы инструментов, обеспечивающие это, включают набор инструментов nosh.