Из-за такого отношения, я лично теперь буду юзать данный дистрибутив, при чём в качестве основной системы. А также стану противником «сыстымдэ», вот чисто назло

Блин, и вы даже не поняли, как сами себя этим унизили! Принимать решения и менять взгляды в зависимости от того, что хрен знает кто что-то там написал в интернете — у вас совсем самоуважения нет, что ли? Прям даже стыдно за вас, когда это читаешь.

Будьте независимее, что ли, и принимайте решения, исходя из объективных критериев, а не сиюминутных эмоций.

Я бы не сказал, что это сию минутная эмоция так как и раньше мне казалось, что данный инит слишком громоздкий, а потом познакомившись поближе shell скриптами мне и вовсе он стал не нужен. А вот теперь я реально ненавижу сыстемдэ. Так как ваше поведение с точки зрения обычного обывателя лора ужасно. Пытаться строчить посты по миллиону раз дабы переубедить оппонента, это уже странно(так при всём при этом вы сами сюда приходите), но вы ещё и оскорбляете пользователей того или иного дистрибутива линукс. Поэтому пока есть такие люди как «Вата» например, я буду противником данного гугловского говна, ведь вы как современные либералы, точно также поносите чужое мнение.

вот теперь я реально ненавижу сыстемдэ

ведь вы как современные либералы

Ты домашку не забыл сделать пока с системой боролся, герой? А то смотри, мамка опять заругает :-D

https://github.com/systemd/systemd/issues/437 пожалуйста

А он другие посты комментирует?

А ведь точно. Это скрипт. На реального человека несильно и похож. Уж слишком отвратительный. У меня тут родилась идея (из серии Теория разговора). Может скрипт написал интелфикс-шаповалов?

Конечно!

Жду, когда systemd внедрят вот в это.

https://github.com/systemd/systemd/issues/8782
сюда же?

Я бы не сказал, что это сию минутная эмоция

Нет, в приведённой выше вашей цитате — именно она.

и раньше мне казалось, что данный инит слишком громоздкий, а потом познакомившись поближе shell скриптами мне и вовсе он стал не нужен

Т.е. вы не можете претендовать на объективность, ибо заранее занимаете сторону.

Не вполне понятно, правда, при чём здесь systemd к скриптам — как будто он не даёт вам запускать те скрипты, которые пожелаете — ну да ладно.

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

Во-первых, кучу сообщений написали обе стороны, и лицемерно с вашей стороны этого не замечать.

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

В-третьих, если вы продолжите ставить своё мнение в исключительную зависимость от того, что кто-то там написал в интернете, то вы останетесь чрезвычайно зависимым и уязвимым человеком, которым элементарно манипулировать «от противного». Вам явно нужно работать над личностным ростом. Надеюсь, что вы ещё подросток, ибо в этом случае такое положение вещей ещё хоть как-то будет объяснимо.

я буду противником данного гугловского говна

«Гугловского говна»? — да у вас каша в голове.

Без обид, но не очень похоже, что вы достаточно компетентны в обсуждаемом вопросе.

ведь вы как современные либералы

…А в Киеве дядька — я понял.

Это сделать попросту невозможно, ибо утилиты rm и mv одни для всех, а APT есть лишь в подмножестве дистрибутивов.

Ну и что? systemd тоже есть лишь в подмножестве портов дебиана. Но авторов APT-а это не остановило.

Замечу при этом, что для совершения такой ошибки нужно произвести явное целенаправленное опасное действие — удаление одного из системных файлов

Ну, обычно перемещение или удаление файлов — это безопасная операция. Юзер просто не знал, что /lib/libdbus-1.so.3 — это важный файл.

в отличие от абсолютно штатного выключения системы.

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

каждое из действий этих пользователей по отдельности абсолютно корректно, но их сочетание уже приводит к проблемам.

Но не только это! Любое изменение файлов + выключение — корректно по отдельности, но может привести к проблемам в сочетании. Так почему мы боремся ТОЛЬКО с apt-ом? Почему бы не решить все подобные проблемы в корне одним махом?

Почему вы исповедуете бинарный подход «или всё, или ничего»?

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

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

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

Более того, тот же shutdown даже рассылает им сообщения в терминалы, что, мол, система будет выключена через N минут, ещё с древних времён.

Да, но мы же хотим предупреждение в обратную сторону — чтобы запускающий shutdown узнал, что выключение может быть небезопасно, и ещё раз подумал. Именно это делает Inhibit. Я просто описываю, как сделать это сразу для всех, без впиливания Inhibit-ов в каждую файловую утилиту.

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

Обычно доступ к консоли всё же есть по KVM, иначе было бы трудно добраться в биос. Но это может быть отключаемая опция. Можно даже спрашивать при установке «есть ли у вас доступ к консоли для интерактивных вопросов при включении или выключении». В любом случае это лучше и универсальнее.

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

Выше были альтернативы. Каждая из них делается изменением только systemd (команда shutdown тоже входит в systemd).

На мой взгляд, предоставление приложениям API, который те могут использовать как захотят для решения своих задач, — это как раз предоставление программам большей свободы действий, нежели если всё будет решать сам systemd.

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

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

Ты домашку не забыл сделать пока с системой боролся, герой?

Ты мужчина стопроцентный – Это видно по делам. Твой пример для нас бесценный, Есть чему учиться нам!.

Ну и что? systemd тоже есть лишь в подмножестве портов дебиана. Но авторов APT-а это не остановило.

При чём здесь порты? systemd — init по умолчанию в основном дистрибутиве, а там, где его нет (что сколько там сотых процента составляет?), пакет собирается без его поддержки.

Предлагаете встроить в rm поддержку всех-всех менеджеров пакетов? Кажется, это явный перебор.

Ну, обычно перемещение или удаление файлов — это безопасная операция. Юзер просто не знал, что /lib/libdbus-1.so.3 — это важный файл.

Вы сейчас всерьёз сказали, что удаление файла — безопасная операция?

Удаление системного файла — это деструктивная операция сама по себе. В отличие от штатного завершения работы.

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

И при этом с самой системой ровным счётом ничего не случится. Речь именно о предотвращении приведения ОС в абсолютно нерабочее состояние, что исключает её починку средствами самой ОС.

Но не только это! Любое изменение файлов + выключение — корректно по отдельности, но может привести к проблемам в сочетании. Так почему мы боремся ТОЛЬКО с apt-ом? Почему бы не решить все подобные проблемы в корне одним махом?

Не любая проблема приводит к неработоспособности системы.

Не понимаю, почему вы к этому прицепились. Для чего была введена данная функциональность, указано в сообщении коммита и соответствующем отчёте об ошибке. Вас не устраивает, как разработчики APT решили предотвратить указанную проблему? — пишите им багрепорт, в котором приводите свои доводы против их реализации.

Ведь другие пользователи могли выполнять какое-то действие, которое нельзя будет продолжить после ребута

Это уже их личные проблемы, а не системы. Не хотите, чтобы вас прервали — запускайте через systemd-inhibit.

Или могли редактировать какой-то системный конфиг, и система не загрузится если прервать редактирование сейчас.

Это ровным счётом никак не решается в вашей схеме, поскольку при завершении оболочки-лидера сеанса редактору прилетит SIGHUP, и он закроется. Спрашивать на этапе, когда прибиваются оставшиеся процессы, уже поздно — нужно предотвращать завершение работы в самом начале, что systemd и делает.

Все описанные выше альтернативы решают весь класс автоматически, в стиле «я всё сделаю, вам не нужно об этом беспокоиться».

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

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

Давай я сокращу твой ответный пост до одного предложения : «У меня нет ответа зачем я прихожу и трачу своё драгоценное время на постинг который ни к чему не приведёт, так как стороны останутся при своём мнении о данном дистрибутиве GNU/Linux и о systemd в частности»

А, то есть ты просто ламер, путающий ICMP и NTP? Вроде бы уже пора привыкнуть к тому насколько хейтеры тупые, но всё-равно каждый раз удивляюсь.

Отлично - мигрировал с Bullseye, а заодно с гнома на XFCE, сразу накатил openrc.

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

Вычистил всё лишнее, пока кроме NetworkManager и Pulseaudio. На старте в таком виде занимает около 400 Мб. Грузится и выключается мгновенно, и без всяких двухминутных Stop Job is running for User Manager… как раньше!

Грузится и выключается мгновенно

Так и должно быть. С systemd это недостижимо.

Так и должно быть. С systemd это недостижимо.

Почему же, фанатик системгэ всегда может выключить компухтер выдёргиванием вилки с розетки, после чего дрочить на быструю загрузку системгэ-поделия в перерывах между проверками ФС. А в запуске длительных проверок всегда можно обвинить кривые ФС. Разумеется лауреат премии Pwnie Awards 2017 в номинации „самая тупая говнокодерская отмазка года” и по совместительству главный разработчик божественного поделия тут ни при чём.

Grzegorz

Кстати, напомню индексы CVE, за которые Лёня и его божественное поделие были награждены премией: CVE-2017-9217, CVE-2017-9445, CVE-2016-10156, CVE-2017-1000082.

Grzegorz

Top 10
Наиболее обсуждаемые темы этого месяца:
Devuan 4.0 (стр. 9) (417)

Мини-новость

Непредвзятость зашкаливает.

Grzegorz

Непредвзятость зашкаливает.

Тут админы такие…про Double Commander, которая еще только бетка, новость на главной.

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

Так и должно быть. С systemd это недостижимо.

Ага. Ведь совершенно невозможно выполнить systemctl edit user@.service и установить там время ожидания завершения процессов такое же маленькое, как в sysvinit:

[Service]
TimeoutStopSec=10s

Ну разве хоть кто-то в принципе способен произвести такую уму непостижимую операцию?

(Не говоря уже о том, что если зависает какой-то из пользовательских процессов и не реагирует на сигнал завершения, то следует именно с этой проблемой разбираться, а не загребать её под ковёр — но, понятное дело, это ещё сложнее, чем установить таймаут в настройках! А поскольку вы авторитетно заявили, что последнее недостижимо, то уж тут-то не стоит и пытаться: ведь совершенно невозможно открыть журнал за предыдущую загрузку и посмотреть, какой именно процесс был прибит по таймауту — это требует просто недостижимого уровня интеллекта!)

Эх, а у меня нет таких. Ubuntu 5.04, 5.10 есть, SuSE 9.2 и 9.3, Mandrake 10.0, куча Mandriva, ASPLinux 9.0, 9.2, 10, 11…

Ха! А таких нет у меня. 🙂 Есть RedHat Linux, Debian, позже Fedora... Но все самозаписанные, без фабричных коробок.

SuSE в виртуалку не поставились, как и Mandrake: не смогли распознать CD и жёсткий диск, соответственно.

0_o У меня даже knoppix 3.1 в qemu запустился, а он, между прочим, из 2002-го года.

Ubuntu же установилась (вот и пример проблем, кстати)

apt-get install console-cyrillic? Или тогда уже был dpkg-reconfigure console-setup?

В графике всё было на удивление неплохо: KNOPPIX_V3.3-2003-11-14-EN LiveCD — в офисе (кроме abiword-а) даже нашлись русские шрифты. И это — в немецком(!) дистрибутиве.

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

Загребать проблемы под ковёр — это именно то что делает Лёня в случае удалённого выполнения кода через DNS-ответ или запуском сервисов от пользователя с именем 0day и за что получает заслуженные премии.

ведь совершенно невозможно вывести на экран какой именно процесс будет прибит по таймауту — это требует просто недостижимого уровня интеллекта!

Починил.

Grzegorz

При чём здесь порты? ... (что сколько там сотых процента составляет?)

Ну это ваша фраза «утилиты rm и mv одни для всех, а APT есть лишь в подмножестве дистрибутивов», только развёрнутая в «apt один на всех, а systemd есть лишь в подмножестве портов».

Предлагаете встроить в rm поддержку всех-всех менеджеров пакетов? Кажется, это явный перебор.

Мне тоже кажется, что это перебор. Но и встраивание зависимости apt-а от systemd мне кажется перебором.

Хотя если продолжать эту логику, то в основных дистрибутивах это только rpm и dpkg. Остальные — лишь «сотые процента».

Вы сейчас всерьёз сказали, что удаление файла — безопасная операция?

Это было не про systemd, а про то, почему мы боремся с маловероятной проблемой выключения при обновлении, но не боремся с куда более вероятными, такими как случайное удаление системного файла.

И при этом с самой системой ровным счётом ничего не случится. Речь именно о предотвращении приведения ОС в абсолютно нерабочее состояние, что исключает её починку средствами самой ОС.

Опять таки, речь о других, не менее вероятных (и ещё более страшных) ошибках, которые этим решением почему-то игнорируются.

Это уже их личные проблемы, а не системы. Не хотите, чтобы вас прервали — запускайте через systemd-inhibit.

С этой точки зрения у apt-а вообще никаких проблем не было. Если пользователь хочет, чтобы обновление не прервалось, то запустит через systemd-inhibit. Тогда... зачем было встраивать интеграцию в сам apt?

Это ровным счётом никак не решается в вашей схеме, поскольку при завершении оболочки-лидера сеанса редактору прилетит SIGHUP, и он закроется.

Решается в альтернативе, где shutdown просто предупреждает о других активных пользователях.

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

Он может посмотреть в списке процессов. А если там ничего такого нет, то может сделать shutdown -r +30, и все увидят, что скоро перезагрузка.

Плюс на том этапе, на котором вы предлагаете, что-то делать уже поздно.

Напомню, там было две альтернативы:
1. shutdown предупреждает, если есть другие активные сеансы пользователей (так же, как это делается для активных ингибиторов)
2. при выключении init-скрипты спрашивают, если какая-то программа долго не завершается (опционально, отключается, если при установке пользователь выбрал «нет доступа к ядерной консоли»)

Могу насочинять ещё:
3. При выключении не посылать KILL программе до тех пор, пока идёт запись на диски.
4. Встроить в apt (ну, точнее, в dpkg) встроенный механизм быстрого отката операции по sigint/sigterm, который откатит всё за несколько секунд (удалит новые файлы, переименует на место старые).

И так далее...

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

Вас не устраивает, как разработчики APT решили предотвратить указанную проблему? — пишите им багрепорт, в котором приводите свои доводы против их реализации.

Меня не устраивает, что эта проблема в принципе решалась. Ведь решать надо было не её.

А из того, что она таки была «решена», я делаю вывод, что это — просто оправдание, чтобы использовать «новую прикольную фичу — ингибиторы».

И против этой логики мне нечего писать в багрепорте. На вопрос «почему вы сделали именно так» они ответят «а почему нет»?[*]

[*] Мы никогда не поймём этого, Гермиона Грейнджер. Но по крайней мере сейчас я знаю, что ответило бы истинное зло, если бы мы спросили, зачем оно творит зло. Оно бы ответило: «Почему нет?»

Ха! А таких нет у меня. 🙂 Есть RedHat Linux, Debian, позже Fedora… Но все самозаписанные, без фабричных коробок.

Не, самозаписанных у меня тоже полно. Но т.к. с интернетом в то время было всё печально, проще было купить.

0_o У меня даже knoppix 3.1 в qemu запустился, а он, между прочим, из 2002-го года.

Запустились-то все — установиться смогли далеко не. При этом ASPLinux 9.0, который начала 2003, встал нормально. Так что это проблемы конкретных дистрибутивов; заморачиваться и искать пути решения не стал.

apt-get install console-cyrillic? Или тогда уже был dpkg-reconfigure console-setup?

console-setup не было (он во времена squeeze появился, если мне память не изменяет), а это диалоговое окно выдалось при установке дистрибутива. Те версии Ubuntu устанавливались в 2 этапа: сначала базовая система с копированием остальных пакетов на диск, а потом перезагрузка и установка оставшихся пакетов уже из минимальной системы; никакого console-cyrillic, ясное дело, там ещё не было.

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

совершенно невозможно выполнить

Это не кошерно, и не секюрно.

если зависает какой-то из пользовательских процессов и не реагирует на сигнал завершения

Ты про systemd?

Ну это ваша фраза «утилиты rm и mv одни для всех, а APT есть лишь в подмножестве дистрибутивов», только развёрнутая в «apt один на всех, а systemd есть лишь в подмножестве портов».

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

Хотя если продолжать эту логику, то в основных дистрибутивах это только rpm и dpkg. Остальные — лишь «сотые процента».

Пользователи Arch сейчас сильно обиделись. 🙂

Это было не про systemd, а про то, почему мы боремся с маловероятной проблемой выключения при обновлении, но не боремся с куда более вероятными, такими как случайное удаление системного файла.

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

А почему именно выключение, я же писал уже: удаление системного файла — это явное деструктивное действие, и если пользователь его выполнил, то он ССЗБ. При этом возможные проблемы из-за выключения системы уже носят неявный и неочевидный характер.

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

Опять таки, речь о других, не менее вероятных (и ещё более страшных) ошибках, которые этим решением почему-то игнорируются.

А с чего вдруг мы не должны решать данную конкретную проблему лишь потому, что существуют другие? Одно другого не исключает.

С этой точки зрения у apt-а вообще никаких проблем не было. Если пользователь хочет, чтобы обновление не прервалось, то запустит через systemd-inhibit. Тогда… зачем было встраивать интеграцию в сам apt?

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

Он может посмотреть в списке процессов

Во-первых, далеко не всегда: см. hidepid в man proc.

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

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

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

1. shutdown предупреждает, если есть другие активные сеансы пользователей (так же, как это делается для активных ингибиторов)

Это происходит и сейчас.

2. при выключении init-скрипты спрашивают, если какая-то программа долго не завершается (опционально, отключается, если при установке пользователь выбрал «нет доступа к ядерной консоли»)

Если следовать вашей логике, то зачем решать проблему таким образом, если она не решается для всех случаев? — простите, не удержался. 🙂

Хорошо, имеем процесс nano /etc/fstab.

Во-первых, как определить при выключении, в каком состоянии находится редактирование данного файла?

Во-вторых, толку, если выбор стоит лишь между прибить процесс и вечно ждать его завершения?

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

Ну и кроме того, зачем интерактивно спрашивать пользователя, можно ли завершить процесс dpkg, если заранее точно известно, что нельзя?

3. При выключении не посылать KILL программе до тех пор, пока идёт запись на диски.

Что вы подразумеваете под записью? Активная запись на диск? — но тогда приведённый вами же пример с редактированием системного файла не решается, ибо реальная запись идёт лишь при сохранении. Открытие файла на запись? — но тогда процесс выключения не завершится в случае зависших процессов. Опять предложите интерактивно спрашивать?

4. Встроить в apt (ну, точнее, в dpkg) встроенный механизм быстрого отката операции по sigint/sigterm, который откатит всё за несколько секунд (удалит новые файлы, переименует на место старые).

Поддержку транзакций было бы неплохо запилить независимо от обсуждаемой проблемы, конечно.

Однако что такое «быстро»? Предлагаете в лучших традициях sysvinit поставить sleep и молиться, что его хватит?

Меня не устраивает, что эта проблема в принципе решалась. Ведь решать надо было не её.

Разработчики APT решили проблему так, как они могли сделать в рамках APT. Опять же, если у вас есть гениальная идея, как сделать более универсальное решение, — добро пожаловать в рассылку/BTS.

Это не кошерно, и не секюрно.

Ну да, редактирование конфигурации штатным способом — явный моветон, ага.

Ты про systemd?

Нет, про пользовательский сервис. Вы же в курсе, что обсуждаемое сообщение выводится, когда systemd --user ожидает завершения всех пользовательских сервисов, да? И дело именно в каком-то зависшем процессе (dbus, pulseaudio, pipewire, …), завершения которого ждёт systemd --user, и завершения которого в свою очередь ждёт systemd. Узнать, какой именно процесс вызвал ожидание, можно из логов предыдущей загрузки.

Но нет, мы простых путей не ищем.

Но нет, мы простых путей не ищем. И дело именно в каком-то зависшем процессе

А что делать, если systemd user process segmentation fault? Что делать, если перезапуск не помогает?

core: serialize u->pids until the processes have been moved to the scope cgroup  
    Otherwise if a daemon-reload happens somewhere between the enqueue of the job
    start for the scope unit and scope_start() then u->pids might be lost and none
    of the processes specified by "PIDs=" will be moved into the scope cgroup.`

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

Держи меня в курсе и дальше.

А что делать, если systemd user process segmentation fault?

Тогда, очевидно, этого процесса не будет, и ждать будет некого.

Держи меня в курсе и дальше.

Всенепременно!

Тогда, очевидно, этого процесса не будет, и ждать будет некого.

Не шлангуй. Ты не ответил на мой вопрос, а именно

Что делать, если перезапуск не помогает?

И смотри на core: serialize u->pids

Не шлангуй. Ты не ответил на мой вопрос, а именно

Что делать, если перезапуск не помогает?

Во-первых, я ответил на другой ваш вопрос, что, конечно, очень сложно было понять, учитывая, что я привёл цитату, на которую отвечал:

А что делать, если systemd user process segmentation fault?

Тогда, очевидно, этого процесса не будет, и ждать будет некого.

Во-вторых, перезапуск чего? В сообщении коммита ни о каком перезапуске речь не идёт. Данный коммит исправлял ошибку, при которой идентификаторы процессов могли не быть помещены в нужный scope — какая связь с паузами при завершении работы системы?

Кстати говоря, а как с этим в sysvinit? Допустим, скрипт сервиса завис на выполнении действия stop — в sysvinit ведь нет механизмов установить таймаут ожидания.

Для примера: я просто взял и добавил sleep 10m в execution flow скрипта slim — в результате всё висит на перезагрузке вот уже 5 минут, без малейшей даже индикации того, что вообще происходит.

Для примера: я просто взял и добавил sleep 10m в execution flow

У меня тоже самое было и с systemd. Также, наблюдалось вот это. C sysvinit такого небыло и нету. Правда, с slim такого не делал. Я его не использую.

У меня тоже самое было и с systemd

Что «то же самое»? Для всех сервисов действует или таймаут останова по умолчанию, или же таймаут, указанный в их файле сервиса. В обоих случаях висеть бесконечно он не будет (если это явно не прописано в файле сервиса), в отличие от.

C sysvinit такого небыло и нету.

У вас лично? — ну, поздравляю.

А вот у меня как-то раз при перезагрузке случился глюк, приведший к зависанию процессов, обращавшихся к одному из дисков — systemd, хоть и через несколько минут, но сумел продраться через таймауты, а sysvinit завис бы на первом же sync.

Да и в сети немало примеров: https://forum.mxlinux.org/viewtopic.php?t=43095 — и далее по списку.

Также, наблюдалось вот это

systemd-networkd

При чём здесь это к паузам при завершении работы системы?

Кстати говоря, а как с этим в sysvinit? Допустим, скрипт сервиса завис на выполнении действия stop — в sysvinit ведь нет механизмов установить таймаут ожидания.

В sysvinit их не должно быть.

Там другая парадигма. «stop» в sysvinit — это не обязательно kill процесса, который должен «скоро» завершиться. Это — активная операция.

Например, по stop-у может создаваться резервная копия базы данных (и вообще остановка базы данных — дело небыстрое).

Или был такой пакет unattended-upgrades, ещё до systemd. Его киллер-фича — автоматическая установка обновлений при выключении/перезагрузке системы.

Ясное дело работать он может неопределённо долго. И надо дождаться завершения его работы, не убивая его по таймауту.

Там другая парадигма. «stop» в sysvinit — это не обязательно kill процесса, который должен «скоро» завершиться. Это — активная операция.

Я бы не сказал, что парадигма другая, ибо в том же systemd точно так же можно установить, какую команду (в том числе скрипт) запускать при останове сервиса (ExecStop=…).

Или был такой пакет unattended-upgrades, ещё до systemd. Его киллер-фича — автоматическая установка обновлений при выключении/перезагрузке системы.

Почему «был»? Он есть до сих пор.

Ясное дело работать он может неопределённо долго. И надо дождаться завершения его работы, не убивая его по таймауту.

Поэтому в отдельных сервисах можно установить очень большой таймаут или отключить его совсем.

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

В sysvinit их не должно быть.

Их просто нет.

Что «то же самое»?

То, что я и написал, тебе ответив.

Для всех сервисов действует или таймаут останова по умолчанию

Таймаут не срабатывал.

или же таймаут, указанный в их файле сервиса

Не указан там.

В обоих случаях висеть бесконечно он не будет

Представь себе, что он висел.

При чём здесь это к паузам при завершении работы системы?

А при том, что я сталкивался с этим.

А вот у меня как-то раз при перезагрузке случился

Это в той же самой системе? Если да, то поздравляю.

П.С.

Я очень рад, что ты столько внимания уделяешь sysvinit.

Это две не связанные друг с другом проблемы.
А почему именно выключение, я же писал уже: удаление системного файла — это явное деструктивное действие, и если пользователь его выполнил, то он ССЗБ.

Да, это разные проблемы. Но из одного класса — «проблемы, которые могут сделать систему незагружаемой». Ведь мы так объясняем решение исходной проблемы?

Если это — реальная причина, то мы должны бороться НЕ ТОЛЬКО с этой проблемой, а и с другими из данного класса.

Иначе это было просто оправдание, повод, чтобы воспользоваться новой прикольной штукой — ингибиторами systemd. И да, авторы APT имеют на это право. Даже без поводов и оправданий. С этим я не спорю.

А с чего вдруг мы не должны решать данную конкретную проблему лишь потому, что существуют другие? Одно другого не исключает.

Именно! Зачем решать ТОЛЬКО эту проблему, если альтернативы ВМЕСТЕ с ней решат и другие проблемы, более реальные?

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

Хм... Тогда это ингибиторы systemd не решают проблему, ведь второй пользователь может запустить важный процесс после того, как первый запустил shutdown.

Зато альтернатива №1, предупреждающая о других пользователях, решает её лучше, ведь она предупредит ещё до запуска «важного процесса». Видя, что кто-то что-то делает, пользователь сможет их уведомить (wall), дать им время завершить свои действия (shutdown -r +10), или прервать выключение (shutdown -c).

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

Пожалуй, именно это мне больше всего не нравится в архитектуре ингибиторов — перекладывание проблемы с больной головы на здоровую. Раньше виноват был тот, кто выключил не проверив, что происходит в системе. Теперь виноват весь остальной мир, все программы и все пользователи, которые не уведомили systemd о том, что выключать-то было нельзя...

Хорошо, имеем процесс nano /etc/fstab.
Во-первых, как определить при выключении, в каком состоянии находится редактирование данного файла?

Автоматически? Никак. Только глазами.

Во-вторых, толку, если выбор стоит лишь между прибить процесс и вечно ждать его завершения?

Пишем пользователю. Смотрим в файл сами. Нас же предупредили перед выключением, что есть другие пользователи.

Ну и кроме того, зачем интерактивно спрашивать пользователя, можно ли завершить процесс dpkg, если заранее точно известно, что нельзя?

Да, это тоже вариант — добавить в скрипты выключения конфиг со списком процессов, которые надо ждать, не убивая. Можно записать эту альтернативу под №5. Её плюс — пополнять этот список смогут и сисадмины и мейнтейнеры пакетов, без изменения их кода.

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

Да, активная запись. И да, это не решит пример с редактором, но решит исходную проблему.

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

Открытие файла на запись? — но тогда процесс выключения не завершится в случае зависших процессов. Опять предложите интерактивно спрашивать?

Тоже интересный вариант. Можно обсудить... Но, по-моему, это частный случай варианта №2.

Однако что такое «быстро»? Предлагаете в лучших традициях sysvinit поставить sleep и молиться, что его хватит?

Я имею ввиду научить dpkg делать откат за пару секунд или меньше (если он ещё не умеет). sysvinit давал 20 секунд, кажется, точно не помню... Но в любом случае, этого хватит.

Если это — реальная причина, то мы должны бороться НЕ ТОЛЬКО с этой проблемой, а и с другими из данного класса.

Разработчики APT решили проблему, которую могли решить в рамках APT. Остальные возможные источники проблем уже находятся вне их области ответственности.

У вас очень странные рассуждения: есть множество проблем, которые могут привести к повреждению системы; разработчики APT решили избавиться от подмножества этих проблем, на которое могут повлиять непосредственно; вы же заявляете, что, мол, зачем они это сделали, ведь есть дополнение этого подмножества, которое уже находится вне рамок их проекта.

Пожалуй, именно это мне больше всего не нравится в архитектуре ингибиторов — перекладывание проблемы с больной головы на здоровую. Раньше виноват был тот, кто выключил не проверив, что происходит в системе. Теперь виноват весь остальной мир, все программы и все пользователи, которые не уведомили systemd о том, что выключать-то было нельзя…

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

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

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

Ну и использование inhibit никак не противоречит реализации других механизмов, поэтому я в упор не вижу здесь проблему.

Да, это тоже вариант — добавить в скрипты выключения конфиг со списком процессов, которые надо ждать, не убивая. Можно записать эту альтернативу под №5. Её плюс — пополнять этот список смогут и сисадмины и мейнтейнеры пакетов, без изменения их кода.

И в результате получим вечное ожидание какого-нибудь зависшего dpkg -l, хотя пристрелить его можно безо всякого ущерба для системы.

Если же добавлять в этот список лишь в момент, когда реально выполняется критически важная работа, то поздравляю: вы изобрели ингибиторы, вид сбоку! 😉

Ещё раз повторю — каждая их моих альтернатив решала исходную проблему И дополнительно целый класс других проблем, более реальных

Единственная реальная «альтернатива», о которой вы заявили, это предупреждение, если есть другие пользователи — и это есть уже сейчас, о чём я уже неоднократно вам писал.

Однако если в системе есть другие активные пользователи, то это лишь косвенный признак: в общем случае неизвестно, позволяет ли их активность завершать работу системы. Inhibit на выключение же — это явный признак того, что завершать работу сейчас нельзя.

К тому же, это всё равно не спасёт, например, от того что сам же пользователь запустил установку пакетов в другом tty (или в другом экране screen) и забыл об этом. Лично я неоднократно забывал закрыть программы на других рабочих столах перед завершением сеанса, и меня спасали лишь запросы сохранения файлов, прерывающие выход, — так что мне это видится более чем реальным сценарием.

Остальные же варианты:

при выключении init-скрипты спрашивают, если какая-то программа долго не завершается

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

При выключении не посылать KILL программе до тех пор, пока идёт запись на диски

Это ненадёжный признак, поскольку даже dpkg производит запись на диск не 100% времени.

Встроить в apt (ну, точнее, в dpkg) встроенный механизм быстрого отката операции по sigint/sigterm, который откатит всё за несколько секунд (удалит новые файлы, переименует на место старые)

Ещё раз, «быстро» — это сколько? Ну хватит уже костылей со слипами, наелись уже.

Кроме того, откат не такая простая операция, как вы думаете. Если пакет зависит от другого по Pre-Depends, то тот уже должен быть в установленном и настроенном состоянии к моменту установки данного — как вы собрались откатывать это? А как откатывать результат работы выполняющихся во время установки скриптов (pre/post inst/rm)? Как восстанавливать удалённый в процессе пакет?

Это лишь на первый взгляд кажется простой операцией. По-хорошему, нужно просто делать снимок ФС до операций с пакетами, но их сейчас не умеет множество ФС, включая ту, что используется по умолчанию.

Ага. Ведь совершенно невозможно выполнить systemctl edit user@.service и установить там время ожидания завершения процессов такое же маленькое, как в sysvinit

Чувак, я устанавливал Debian не для того, чтобы копаться в фекалиях потного. Задача была пользоваться для своих конкретных нужд операционной системой, которая всегда преподносилась как самая стабильная, но, видимо, времена стабильности безвозвратно ушли. Даже в дефолтной установке на дефолтное железо проявляются зависшие сервисы, и миллионы пользователей по всему миру - системных администраторов, программистов, дизайнеров, домохозяек и хомячков - лезут конфигурировать системДно сразу после установки этого чуда, параллельно читая changelog изменений с 247-й по 269-ю версию. Могу пожелать только удачи, но мне с ними не по пути.

На мой взгляд, добавочный труд, вкладываемый разработчиками Devuan, просто недостаточен для заявлений, что это отдельный дистрибутив. Если он на 99% состоит из оригинальных пакетов из Debian вообще без изменений, а большинство оставшихся тоже ведь не из воздуха появились и основываются на готовых пакетах оттуда же, то это максимум патчсет над оригинальным проектом. Та же Ubuntu хотя бы пакеты пересобирает, да и оригинальных пакетов в ней гораздо больше — и то многие считают, что она паразитирует на Debian.

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

Парни из Devuan сделали казалось невозможное - вычистили из такого сложного проекта как Debian этот монструозный и переусложннённый системный компонент, который как раковая опухоль расползается по всем даже самым удалённым уголкам некогда славного дистрибутива всё сильней и сильней. Это не 1% изменений, а все 50. Так как 90% програм из репозиториев всё равно никто не пользуется, а система инициализации - важнейший компонент операционной системы.

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

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

А то, что ты не осилил даже в логи заглянуть, чтобы попытаться разобраться в такой простой проблеме, о многом говорит. Причём с немалой вероятностью тот же пользовательский процесс точно так же зависает у тебя и сейчас, но теперь ты этого не видишь. Счастье — в неведении, ага.

мне с ними не по пути.

Как будто хоть кому-то не наплевать. Пользуйся, чем хочешь, «чувак».

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

Ubuntu содержит секцию main самостоятельно; universe — да, берётся из Debian практически без изменений, потому некоторые и считают, что Ubuntu паразитирует на Debian. Однако на мой личный взгляд, она достаточно от него отличается.

Mint аж целое окружение запилили, т.ч. тоже явно не Ubuntu с новыми обоями.

Это не 1% изменений, а все 50

Какие там 50%? — 146%, и ни процентом меньше!

Ubuntu содержит секцию main самостоятельно

Они что - нашли фатальный недостаток в оригинальном main от Debian? Который стоит того, чтобы пилить отдельный диструбутив, поломавший всю совместимость? Похоже на зловредную диверсию против Линукса - распылить силы и посеять смуту на пустом месте. Т.е. они меняют то, что и так идеально работает (Debian main)!

Mint аж целое окружение запилили

Отдельный дистрибутив ради окружения рабочего стола - это просто необходимо. Это вам не системный менеджер, от которого зависит тысяча пакетов, заменить. Это всё 2% будут!

А Devuan молодцы, сохранили совместимость для прикладных програм с Debian. Естественно, которые не стали себя намертво завязывать на то самое-d. И есть вероятность, что пройдут годы, сменятся покаления, и Debian венётся к истокам, взяв их наработки. А Ubuntu канет в лету вместе со своим космонавтом.

P. S. За «чувака» прости, если обидел.

Mint аж целое окружение запилили, т.ч. тоже явно не Ubuntu с новыми обоями.

Ну давайте сядем всем ЛОРом с калькулятором и посчитаем - сколько процентов в Mint напрограммировали по отношению ко всей базе кода Debian, распространяемой на нескольких DVD.

Это их хвалёное «окружение» представляет из себя несколько патчей для гномощели и панельку. И главное их достижение - это то, что они наконец в последней 5-й версии наконец сделали кнопку перезапуска щели, чтобы сбросить утечки памяти. Да, только ради этого стоило замутить отдельный дистрибутив!

Это тебе не системы инициализации и управления демонами типа OpenRC, runit, s6 в дистрибутив, повязанный сложными зависимостями вкорячивать!

Ты всё-таки по области деятельности ближе к маркетологам или к инженерам? У меня, как у программиста, по поводу полезности проекта Devuan вообще никаких вопросов не возникает. Их «жалкий 1%» кода куда ценней тонны неконтолируемой лапши с зондами Поттеринга, заразившей почти все дистрибутивы. Любой без systemd на вес золота - корпорациям не выгодно вкладывать деньги в то, с чего они не могут заработать, поэтому пожелаем удачи и здоровья энтузиастам, ветиранам Юникса!

*ветеранам

Они что - нашли фатальный недостаток в оригинальном main от Debian?

Не буду говорить за то, как было изначально, но сейчас там несколько другая схема поддержки (для LTS — более продолжительная по времени и менее жёсткая в плане заморозки версий, для обычных выпусков — более частые релизы). Плюс ориентация на поставку всего ПО в snap. В данных условиях отдельной песочницы, наверное, не избежать.

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

Понимаю ваш сарказм и отчасти его разделяю. Однако нельзя не отметить, что целое не самое маленькое окружение — это довольно много.

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

Я всегда предпочту, чтобы и полезные наработки Ubuntu, и полезные наработки Devuan — развивались в рамках Debian, а не в отдельных проектах.

Это их хвалёное «окружение» представляет из себя несколько патчей для гномощели и панельку.

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

У меня, как у программиста, по поводу полезности проекта Devuan вообще никаких вопросов не возникает. Их «жалкий 1%» кода куда ценней тонны неконтолируемой лапши с зондами Поттеринга, заразившей почти все дистрибутивы.

Если вы действительно программист, то ваше бездумное повторение бреда про «лапшу» и «зонды» удивляет. Вы либо не видели код systemd, либо не видели код других открытых проектов (по сравнению с тем, что в них попадается, systemd — просто образец хорошего стиля).

Ну, я теперь девьянец.

Парит конечно что многое ломается-меняется с апгрэйдами.

1. Цвета LS_COLORS поплыли. Или вернее, стали какими следуют (видимо?), тёмными. Но раньше они всегда были светлые, и виделось всё отлично на тёмном фоне в терминалах. Задал цвета руками, из 256-цветовой палитры (и для prompt тоже). Ещё пропал жирный шрифт в терминале для терминуса. (Я вообще-то боялся что с терминусом вообще беда будет, придётся компилять старые версии либпанго. Но он заработал более-менее сам.)
2. Выкинули medit, хотя старый deb без особых проблем ставится на новую систему (проблемка есть, но легко решается). Поставил старый деб.
3. Выкинули moby-thesaurus для dict, и никакого другого (для дикт) не добавили. Взял файлики из старой системы.
4. Не компилится стабильная версия avidemux: требует qt4, которую выкинули. В дев-версии вроде есть поддержка qt5, не пробовал. Испугался руками ставить qt4-дев-окружение, просто добросил нужные qt4 либы (прямо so-файлики) в новую систему, чтобы заработал старый бинарник avidemux.
5. Не компилится nufraw: требует gtkimageview виджет для gtk2, который выкинули. Доустановил deb-ы из старой системы, откомпилил.
6. Для терминуса изменился формат (был pcf.gz, стал otb). Ранее (давно) сделанный патч для буквы «б» (она дурацкая по дефолту) потребовал дальнейшей обработки. Скачал исходники, и подсмотрел нужную команду из debian/rules.
7. Пропатчил (сам) свежий qemu чтобы мышь захватывалась-отпускалась по ctrl-alt (по дефолту – g, жутко неудобно). Оказалось несложно, зря боялся.

Все эти проблемы есть и в апстриме = Дебиане 11, т.е. то же самое пришлось бы делать и в Дебиане. Из Девуано-специфичных ништячков — имена сетевых интерфейсов по дефолту нормальные, типа eth0 (без net.ifnames=0 в параметрах ядру), хотя мне это и не нужно. Ну и главное — продолжающееся отсутствие необходимости знать что-либо про системд и прочее ихнее рэдхэтное! :) Это отрадно, и спасибо девуанцам! :) (помню как всё менялось-ломалось в гноме2 при апгрэйдах)

Основной софт: X, xdm, icewm, mc, mocp, mplayer, firefox. Раньше был fsprotect для загрузки read-only, но он выкинут, так что теперь bilibop-lockfs вместо него (пришлось почитать про lvm, и перейти на него).

Много дней колупался — только чтобы апдэйты прилетали ближайшие годы. Потому что вроде ничего нового мне и не нужно в новой системе. Грустно это. Как-то близки мне (в этом смысле) ценности учёных из ЦЕРНа (судя по спорам Евгения с Альфой), которым нужно просто чтобы старое работало, просто работало, а не ломалось. Надеюсь 4 года не буду апгрэйдиться.

Zubok

Для терминуса изменился формат (был pcf.gz, стал otb). Ранее (давно) сделанный патч для буквы «б» (она дурацкая по дефолту) потребовал дальнейшей обработки. Скачал исходники, и подсмотрел нужную команду из debian/rules.

Вообще-то, для terminus два пакета: fonts-terminus И xfonts-terminus. В последнем по-прежнему pcf.gz . Но в итоге все завист от того, куда надо этот Terminus вставить. Например, HarfBuzz с пиксельными шрифтами не работает, поэтому они говорят, что выход - это сконвертировать растр в otb. Для server-side fonts не должно быть изменений.