Про systemd и автозапуск десктопных приложений

После переезда на openSUSE 15.5 я столкнулся с некой странностью. Автозапускаемые после старта приложения стали падать при попытке перезапуска.

Тут надо сказать, что сама по себе идея само-перезапуска (по крайней мере, в мире POSIX) достаточно простая и примитивная. Стартуем новый процесс, копируя ему всё своё окружение (не забывая про открытые файлы) и завершаемся. PPid при этом сбрасывается в наш бывший родительский, и вот. Имеем новый процесс, выглядящий (за исключением pid, конечно) ровно так же как и предыдущий.

Подробнее в дебри я тут лезть не буду. Кому интересно глубже — гуглите реализацию «fork-exec». В linux «fork()» обозвали «clone()», но суть от этого не изменилась. Вот тут — побольше философии.

В Linux fork — это fork, это системный вызов из тех времён, когда в ядре не было неймспейсов, он не принимает никаких параметров. clone — это другой, хоть и похожий, но более новый системный вызов, с помощью которого можно поместить дочерний процесс в другой неймспейс.

На этой технике («respawn») работает в т.ч. обновление всякого десктопного софта. (Если вы конечно ему доверите такое вытворять у себя в системе.) Тот же клиент telegram. Ну и в своём xswitcher я тоже вкрутил подобную возможность.

И вот она-то наглухо «отвяла» после обновления ОС. Везде где была. Попытки дебага показывали что процесс запускается, начинает работать и затем молча дохнет. (Получая то ли sigterm, то ли sigkill. Я поленился встроить в xswitcher обработчик, за что и поплатился непонятками.)

Можно было бы ещё долго удивляться новой странной «магии», если бы не помог случай. Выпуская один хитрый сценарий для контроля топологии сети, решил «быть модным» и вместо всяких cron повесить его на systemd.timer. (Штука там достаточно автономная, так что текущий дизайн не ломает.)

И вот, «на голубом глазу» пишу в юнит-файле:

ExecStart=/bin/bash -c 'ERR=`/usr/local/sbin/xxx-check-topology.sh 2>&1` || (echo "$ERR" | /usr/bin/mail -s "xxx topology error(s) found" root)'

Раскидываю по местам. …И удивляюсь, что почты как-то меньше ожидаемого.

Как так? «Руками» запускаю — вот она, ругань. В зачищенном окружении (обычная проблема для башатины) — тоже. Начинаю копать и выясняю, что этот самый «mail» (который пакуют во всякие «mailutils«, «mailx» и т.п.) работает, оказывается, в асинхронном режиме! (И имеет спец. ключ «-Ssendwait» на случай когда так не надо.)

Применительно к процессам «асинхронный режим» — это, на мой взгляд, неправильная терминология. mail форкается и выходит, не дожидаясь завершения дочернего процесса.

Начинаю гуглить и вижу, что народ на это натыкается достаточно массово. По причине systemd.kill. Начиная с некоторой версии, systemd (безопасно/отказоустойчиво/инклюзивно/wtfElse) расстреливает всё содержимое cgroup при завершении запущенного им процесса. Однако, если процесс изначально стартовал как-то ещё и потом был «сброшен» на systemd-user, этот фокус не работает.

…Вот такое сегодня получилось эссе. Проблему я подсветил, но пока не знаю, как правильно её купировать.

• С одной стороны, можно просто «дать по рукам» systemd. Там есть (см. по ссылке выше) крутилка «не убивать». Но, глядя на перспективу, я так делать опасаюсь. Плод трудов известного сотрудника Micro$oft, конечно, не абсолютное зло. Но однозначно приучает к безалаберности. Больше можно не думать обо всех этих «демонизациях», логировании и прочей IT-гигиене. «Сделай тяп-ляп, а systemd за тобой подотрёт». В любой момент может оказаться, что писатель очередного ПО всю зачистку переложил на systemd.

• С другой стороны, можно попробовать как-то надурить «надзирателя». Написать некую копеечную резидентную прокладку, как вариант. Но такой способ мне видится некрасивым.

На хабре достаточно людей с глубоким пониманием «кухни» ОС. Жду соображений «как правильно» в комментариях.

Всем удачи!