systemd 251

Не скажи. На эту полемику подтянулся сам г-н Столяров. А с ним любой спор, касающийся systemd, становится в разы интереснее и увлекательнее.

Проблема в том что это самое убиение юзер сессии срать хотело на все таймауты. ПО окончании заданного тобой таймаута оно накручивает к нему +60 сек и начинает отсчет снова. Потом оптяь +60. И если у тебя реально там что-то зависло в графике то перезагрузить systemd можно только выключением питания.

Как воспроизвести?

Лёня просто пишет код

Да, пишет. Кто бы сомневался. А ты, этот говнокод, используешь. Ведь ты домохозяйка. Не осилил написание скрипта для sysvinit.

Так это ж хорошо, что теперь линуксом может пользоваться не только гений скриптов sysvinit Odalist, но и обычная домохозяйка

Ждем просьбы Поттеринга переименовать систему в SystemD/GNU/Linux

Не может. Обычная домохозяйка будет работать на винде

ждать и надеяться. Systemd сам решает когда перейти в упоротое состояние вечной остановки юзерсессии.

Ну т.е. всё это из разряда «верьте мне на слово» — ясно, вопросов больше не имею.

это из разряда древнего бага который поттеринг отказался исправлять. Можете порыть историю если есть желание - мне влом. Я редко перегружаю ноут - в основном suspend-resume.

Искать то-не-знаю-что не имею желания. Если бы вы предложили чёткий механизм воспроизведения проблемы, то я постарался бы в ней разобраться, однако без возможности её воспроизвести сделать это малореально.

И если у тебя реально там что-то зависло в графике то перезагрузить systemd можно только выключением питания

Брехня.

Не осилил написание скрипта для sysvinit.

А зачем ему осиливать устаревшую технологию? Мартышким труд оставим мартышкам.

системного менеджера GNU/Linux

Можно ли называть его верховным демоном, повелителем прочих демонов?

Можно ли называть его верховным демоном, повелителем прочих демонов?

Истинно так, да осенит тебя благословение верховного жреца Леннарта!

Это не демон, а сам Люцифер пожаловал в мир смертных.

Оно в gtk реализовано. Эти уроды реализовали mixed dpi support только в бекенде для вейланда. Хотя ничто не мешало реализовать его и в бекенде для икс11. Но они ж закапывают икс11 в угоду вейланда. Тут все средства хороши.

Прекрати текстовый слой ломать, олигатор.

Вся подсистема работы с секретами,systemd-creds, опция LoadCredential и всё вокруг них выглядят очень круто. Надеюсь, RedHat позаботится о том, чтобы встроенный в дистрибутив софт (приходят в голову OpenSSH и Apache httpd) будет это использовать.

Подумал о поддержке этого в CertBot и в nginx. Последний в конфиге не умеет переменные окружения использовать, нужно ещё envsubst взять.

mailx существует многие годы.

Это часть работы по реализации идей из https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html

Всё-таки Леннарт - один из лучших системных архитекторов GNU/Linux.

Если бы вы предложили чёткий механизм воспроизведения проблемы

Тебе же сказали - плавающий баг, ну какой в плавающем баге может быть четкий механизм воспроизведения ?

Воспроизведение - перезагружаешь\выключаешь компьютер. В рандомное время, в зависимости от хер знает чего, systemГ выдает stop job is running for session c1 of user ЮЗЕР 1min 30s

Чот ржанул с

It is highly recommended for the system to have swap enabled for systemd-oomd to function optimally

Типа «ваши приложения будут работать устойчивее, если в системе будет своп, но всё это конечно же благодаря не свопу, а аж нашему systemd-oomd».

И толку. Если Леннарт в багрепорте написал что бесконечное убивание юзерсессии это не бага а фича и никаких фиксов принято не будет. Года два или три уже как народ жаловался на околобесконечное завершение user session при ребуте.

К сожалению могу подтвердить его слова… Встречался несколько раз в дебиане с подобным поведением…

Воспроизведение - перезагружаешь\выключаешь компьютер. В рандомное время, в зависимости от хер знает чего, systemГ выдает stop job is running for session c1 of user ЮЗЕР 1min 30s

Так вопрос-то не в этом. Qui-Gon написал:

Проблема в том что это самое убиение юзер сессии срать хотело на все таймауты. ПО окончании заданного тобой таймаута оно накручивает к нему +60 сек и начинает отсчет снова. Потом оптяь +60. И если у тебя реально там что-то зависло в графике то перезагрузить systemd можно только выключением питания.

С таким ни разу за все годы использования systemd не сталкивался. Так что можно хоть наперезагружаться вволю.

Если Леннарт в багрепорте написал что бесконечное убивание юзерсессии это не бага а фича и никаких фиксов принято не будет

Ну так дали бы ссылку на этот багрепорт — интересно же.

Мартышким труд оставим мартышкам.

Вижу, ты стал экспертом по поттеринговским высерам.

а встроенный почтовый мини-клиент

И встроенные иксы с каким нибудь systemd DE. И все это вертится и крутится на ядре, написанным самим Лёней. Наверно это предел твоих желаний.

интересно же.

Читай Тут.

Печально, любимый Debian когда-то «просто работал»

Встречался несколько раз в дебиане с подобным поведением…

Что характерно, я тоже встречался именно в дебиане.

После того, как я обнаружил, что они включают сервисы по умолчанию после установки пакета, я уже ничему не удивляюсь. Я даже не поленился и поискал зачем они это делают: оказалось, что в целях совместимости с sysv init. Хотя, казалось бы, зачем?

Каждый раз, сталкиваясь с дебианом, мне кажется, что его делают рептилоиды для рептилоидов, со своей рептилоидной логикой.

По данной ссылке лишь про обычные сообщения «A stop job is running for User Manager for UID…» и жалобы на необходимость ждать 2 минуты при завершении работы системы. У Qui-Gon речь же о том, что таймауты якобы постоянно увеличиваются, превращая ожидание в бесконечное — вот про это я и хочу почитать.

они включают сервисы по умолчанию после установки пакета

В Debian делают systemctl preset, что, вообще-то, является рекомендованным поведением.

И да, в этом есть своя логика, и да, это элементарно настраивается.

$ locate .preset 
/usr/lib/systemd/system-preset/90-systemd.preset
/usr/lib/systemd/user-preset/90-systemd.preset
/usr/share/man/man5/systemd.preset.5.gz

Смотрим что там есть про какой-нибудь апач:

$ grep "apache2" /usr/lib/systemd/{user,system}-preset/90-systemd.preset

Устанавливаем этот апач, смотрим что с ним:

# systemctl status apache2
● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2022-05-24 15:38:10 MSK; 18s ago
       Docs: https://httpd.apache.org/docs/2.4/
   Main PID: 266171 (apache2)
      Tasks: 55 (limit: 9145)
     Memory: 5.6M
        CPU: 59ms
     CGroup: /system.slice/apache2.service
             ├─266171 /usr/sbin/apache2 -k start
             ├─266173 /usr/sbin/apache2 -k start
             └─266174 /usr/sbin/apache2 -k start

Повторяем то же самое в какой-нибудь федоре, чувствуем разницу.

По умолчанию preset включает устанавливаемые сервисы. В Fedora просто стоит дефолтное правило disable *, перезаписывающее это поведение.

Ну вот мне и стало интересно, почему такое разное поведение. Дебиановцы ссылаются на соместимость с поведением sysv init.

Мне кажется, что логика

поставить пакет -> редактировать конфиг -> включить сервис

чуть более простая, чем

поставить пакет -> выключить сервис -> редактировать конфиг -> включить сервис

или

подложить конфиг заранее -> поставить пакет -> включить сервис

И всё у них так, пляски с напильником на ровном месте.

Дебиановцы ссылаются на соместимость с поведением sysv init

Где?

Ссылаться на поведение sysvinit глупо, поскольку поведение sysvinit также было явным решением разработчиков. И исходит оно из логики «поставил и сразу пользуешься», которая применима в большинстве случаев.

Если вас не устраивает это поведение, то ничто не мешает вам создать собственный preset-файл с disable *.

поставить пакет -> выключить сервис -> редактировать конфиг -> включить сервис

В Debian Политика (основополагающий технический документ) предписывает поставлять все сервисы в безопасной и полезной конфигурации по умолчанию, так что чаще всего это так:

ставишь пакет → пользуешься

— вместо:

ставишь пакет → включаешь и запускаешь сервис → пользуешься

Не забывайте, что во время установки могут задаваться вопросы для первоначальной настройки, если это требуется. (Preseeding тоже есть.) Если же данный конкретный сервис не следует включать по умолчанию, то в пакете с ним может идти соответствующий preset-файл, как например в fwupd:

disable fwupd-refresh.service

сначало надо ядро под нее написать :о)

Так вопрос-то не в этом. Qui-Gon написал

Так и есть. Какая к черту разница, несколько минут, или несколько раз по 60 секунд ?

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

В соседней винде такое тоже есть. Только там в отличие от systemd, система предлагает прибить процессы, мешающие выключению, и если ты внимательно читал, то Лёне предлагали сделать такую же фишку в его systemГ: «Process <httpd> wants more 10 sec to graceful shutdown, force kill it? yes\no». Или хотя бы не игнорировать собственные настройки таймаутов: если я поставил глобально ждать 10 сек, то сцука завершать на 10-й секунде, а не «ой, 10 сек, но с процессом какая-то херня, поэтому будет сколько нужно».

С таким ни разу за все годы использования systemd не сталкивался. Так что можно хоть наперезагружаться вволю.

А я все эти годы ездил бухим на красный. Все, с КОАПа можно эти статьи вычеркивать.

Баг - это когда у кого-то НЕ работает, а не у тебя работает.

А суть их в том, что в рандомное для пользователя время, он не может выключить компьютер, и у него нет информации о том что это, и как это прервать.

Ждёт завершения процесса в течение пары минут ≠ не может выключить.

Хотя с тем, что имя сервиса/процесса выводить стоило бы, согласен.

Или хотя бы не игнорировать собственные настройки таймаутов: если я поставил глобально ждать 10 сек, то сцука завершать на 10-й секунде, а не «ой, 10 сек, но с процессом какая-то херня, поэтому будет сколько нужно».

Где там про игнорирование настроек таймаутов?

Баг - это когда у кого-то НЕ работает, а не у тебя работает.

1. Я попросил рецепт воспроизведения проблемы.

2. Вы написали, что это плавающий баг, и что для воспроизведения нужно перезагружать/выключать компьютер[, и когда-нибудь это случится].

3. На что я написал, что у меня за много лет ни разу не случилось.

Очевидно, что речь шла о невозможности воспроизведении проблемы у меня, а не об отрицании её существования в принципе.

И раз уж пошла такая пьянка.

А как себя поведёт sysvinit, если в каком-нибудь init-скрипте какая-нибудь mysqladmin shutdown зависнет и не будет отвечать на сигналы?

А как себя поведёт sysvinit, если в каком-нибудь init-скрипте какая-нибудь mysqladmin shutdown зависнет и не будет отвечать на сигналы?

Сказано — сделано! Уже 15 минут висит, на Ctrl+C ожидаемо не реагирует.

Ну и за killall mariadbd руки бы поотрывать.

Как же меня зае@#$ рандомные зависания при выключении компа с эпичным «A stop job is running for User Manager for UID 1000»

О, коллега :)))

Кроме этого, sysD не напрягает как-то ничем. Давным-давно ещё ко всяким астерискам просто кривые юниты прилагались, но лет 5 уже не встречал такого.

Ну вот ты и признался в том, что старые проблемы systemd не решил, а новых манов подобавлял.

После того, как я обнаружил, что они включают сервисы по умолчанию после установки пакета, я уже ничему не удивляюсь.

Всегда так было. Что не так?

Дебиановцы ссылаются на совместимость с поведением sysv init

Где?

Где-то в своих рассылках. Ссылку, естественно, не сохранил.

И исходит оно из логики «поставил и сразу пользуешься», которая применима в большинстве случаев.

Никого не смущает, что десктопную программу нужно запускать, клацая мышой по иконке, или добавлять в автозапуск. Почему энджинкс или постгрес у меня должны сразу запускаться в какой-то среднетемпературной конфигурации, чем это удобно?

Не забывайте, что во время установки могут задаваться вопросы для первоначальной настройки, если это требуется

В Ансибле, наверное, очень удобно в этих случаях что-то описывать :3

Оно и так получается, что надо всю эту кривую логику в голове держать, а тут, видимо, просто праздник какой-то. Наверное, и модули есть специальные для управления всем этим хозяйством.

ничто не мешает вам создать собственный preset-файл с disable *

Как ничто не мешает мне создать собственный .xsessionrc c . ~/.profile, чтобы он у меня выполнялся в графическом сеансе.

И ещё в массе мест поработать напильником, чтобы было чуть-чуть удобнее жить.

Я же говорю, всё у них так.

Ну вот ты и признался в том, что старые проблемы systemd не решил, а новых манов подобавлял.

Вполне себе решил: в описанной ситуации с зависшим mysqladmin shutdown systemd подождёт отведённое сервису время и завершит его принудительно.

Система с sysvinit же всё ещё висит — жду ценных советов от мастеров говна и палок, как же мне нормально завершить её работу, не прибегая к Reset/SysRq.

Никого не смущает, что десктопную программу нужно запускать, клацая мышой по иконке, или добавлять в автозапуск.

Потому что десктопные программы в подавляющем большинстве своём запускаются и завершаются по необходимости, а демоны на то и демоны, что предназначены для постоянной работы в фоне.

Ну а если сервис для постоянной фоновой работы не предназначен, то его сопровождающий отключит его автозапуск через preset-файл. Или же это сделает администратор, если ему так захочется.

А вообще, попытка строить рассуждения о фоновых сервисах, отталкиваясь от другого класса программ — десктопных, работающих на переднем плане — попахивает демагогией.

В Ансибле, наверное, очень удобно в этих случаях что-то описывать :3

Написал же: есть preseed. Плюс уровни debconf.

Я же говорю, всё у них так.

Это какой-то синдром утёнка напоминает, если честно. Ваш брат-близнец из параллельной вселенной, начинавший на Debian, наверное, точно так же жалуется, что, мол, на этих ваших редхатах надо все сервисы вручную включать после установки — «разве того, что я их поставил, недостаточно, чтобы понять, что я собираюсь их использовать?»

И столько слов из-за одной строчки в конфиге, позволяющей сделать так, как вам удобно (= как вы привыкли), при том что на настройку самих сервисов вы потратите значительно больше строчек и времени…

и завершит его принудительно

как же мне нормально завершить её работу

Так нормально, или принудительно ?

Так нормально, или принудительно ?

Ну /facepalm же.

Завершит принудительно сервис. Нормально завершить работу системы (т.е. прибить зависший сервис, корректно остановить остальные, размонтировать ФС и т.д.).