Боян с кучей ошибок разного рода. Язабан.

ура, у нас есть сайт

Знатно бомбит у хейтеров

/me CRUX'о'боярин смотрит с высока на systemd-проблемы.

Потом Поттеринг придёт за софтом, которым ты пользуешься.

А ты быстрый. Как загрузиться в генту? (комментарий)

Криокамера протекла, да?

По сабжу: забыл добавить в теги «сопли», «нытьё», «не осилили»

Хорошо все расписали.

Как всегда, школофанаты поццеринга делают невероятное открытие из того, что остальные и так давно знали. :)

с кучей ошибок разного рода

Список ошибок в студию!

https://news.ycombinator.com/item?id=7639170

Бойкотирование systemd

Читал хоть? Там не одного технического замечания нет. Только «могут быть ошибки», «коредампы в journald», «не соответствует философии unix» и прочий бред ГСМ'а.

L.Poettering:

From all these talks I figured out that the Unix philosophy is:
1) Everything was already invented and perfect 40 years ago.
2) Everything else must be implemented using shell scripts and pipes.

Да, читал. Начнем с того, что гном 3.8+ linux-only, и логика е***есь как хотите это плохо. И так будет со всем софтом, который привяжется к systemd.

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

закопайте

и не стыдно врать? гном на systemd не завязан ни разу, кроме GDM, да и тот от специфичных частей не зависит. курить до просветления.

по ссылке все верно, но про гном лютое 4.2. УМВР.

По первой ссылке местами 4.2. Особенно про пункт 11. Факт в том, что systemd усиленно форсят. Дебаты в техническом комитете Debian и в рассылке очень показательны.

Ну-ну. Сия цитата кровавого Поцеринга показывает, что он не разбирается в вопросе.

https://news.ycombinator.com/item?id=7639170

По первой ссылке типичный опеннет-стайл с бесконечным переливанием из пустого в порожнее, оправдания в духе «не нраица journald — ставь syslog» и непонимание сути претензий. Особенно порадовало:

systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system.

Not true, again. Right now, on my system:
1 systemd
354 systemd-journal
386 systemd-udevd
766 systemd-logind

Т.е. товарищ даже не понял, о чём речь. Зато там же есть хорошие примеры, почему авторы systemd — чудаки на букву 'м'.

По второй ссылке типичный срачик (и я там был, если ты не заметил). Так где ошибки-то?

Бомбеж пуканов продолжается. Я даже завидую Поттерингу - так троллить красноглазую школоту безусловно великий талант нужно иметь.

кроме GDM

Я не слежу за гномом, начиная с 3.х. Может там и враки, может уже все перепелили. Факт остается фактом: systemd не переносим. Любой переносимый софт, завязавшись на systemd становится де-факто «не нужно».

Бомбеж пуканов
троллить
красноглазую школоту

Вся суть убогеньких поццерингофагов в одном посте.

да, поэтому я против systemd. но фанатики-параноики меня тоже раздражают - увидев страшное слово «systemd» в новостях про GNOME, не разобрались, что к чему, а просто начали кукарекать. так же было с udev. больные люди.

Когда оно строилось в таком виде - никому дела не было.
А теперь, с грядущим переходом дебиана и убунты на systemd на становится стандартом de-facto, а всё остальное автоматически опускается до уровня узкоспециализированной маргинальщины.
Бороться с этим надо было года два назад. Щас - всё.
будущее линукса будет вот таким.

P.S. Инициативная группа, часом, не с Киева?

меня записывайте в противники.

правильный выбор

Я не использую системд и пока не собираюсь. Но ни разу ни одного вменяемого аргумента против него не слышал. Ну кроме кукареканья про заговор Red Hat, bloatware и прочую ахинею.

Я не использую системд и пока не собираюсь

Другими словами, «не читал, но защищаю».

Ну кроме кукареканья про заговор Red Hat

Невероятно избирательное зрение и память.

У нас тут в команде четвертый день пишут workaround-ы для init-скриптов, которые не могут остановить необходимые сервисы, не могут правильно выяснить pid процессов, теряют pid потомков и т.д. и т.п. При этом pgrep, pidof, pstree и прочие башовые однострочники, а точнее построенные из их костыли, обернутые перловыми скриптами падают в непредсказуемых местах в зависимости от размеров строки, локали, нагрузки на системе или погоды на Марсе.

Но вы бойкотируйте, бойкотируйте.

элементарные вещи не работают? выбираете systemd? наблюдаю корреляцию

Отличный комментарий :)

ИМХО, надо единицу измерения адекватности вводить: одна альфа.

systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system.

Not true, again. Right now, on my system:
...

Т.е. товарищ даже не понял, о чём речь.

Насколько мне известно, сам systemd, собранный без лишних опций, занимается только критичными задачами:

• парсингом юнит-файлов
• резолвингом зависимостей
• контролем cgroups
• обработкой событий типа «кто-то просит запустить сервис»/«кто-то стучится в сокет»/«кто-то дергает дбас»

Всевозможные фичи, из-за которых он считается комбайном, вынесены в отдельные бинари.

Итак, о чем речь и чего не понял товарищ?

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

У нас

Как же хорошо, что я пидорой не стал пользоваться.

парсингом юнит-файлов
резолвингом зависимостей

Это уже немало, учитывая, что этих юнитов несколько типов, у каждого вагон и маленькая дрезина опций, и кол-во этих опций постоянно растёт. Закрадётся вот в парсер баг, приводящий к сегфолтам (а сегфолты на конфигах не такая уж и редкость) и всё, крантец. Если бы этим хотя бы systemctl занимался.

элементарные вещи не работают?

Именно что элементарные, и именно что не работают.

выбираете systemd?

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

Именно что элементарные, и именно что не работают.

А виноваты те кто не любят systemd? Может они пардон вам и в штаны нагадили?

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

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

Ну ты перечитай, где ты там каких-то виноватых нашел.

Я говорю лишь о востребованности новой(для некоторых) технологии в реальных задачах.

Да, но она работает в конторе, у которой демоны строят деревья процессов и by design становятся зомби!

Я хейтер только тогда, когда мне говорят, что демон ИМЕЕТ ПРАВО зависать, кордампиться и вообще не работать - все эти проблемы должна решать... простите... система инициализации.

собранный без лишних опций

Гыгы. Кто ж его соберёт, пока debian его не допилит???

Маразм крепчал, очки сползали

Читал уже этих наркоманов. Особенно раздел What You Can Do доставил. Да, побежали делать мод для xBill, больше ведь всё равно не в состоянии сделать ничего.

демон ИМЕЕТ ПРАВО зависать, кордампиться и вообще не работать

Демон к сожалению забывает тебя спросить о том, имеет он какие-то права или нет. Он просто падает(в лучшем случае), или не падает, а съедает 100%CPU и не реагирует на SIGTERM.

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

И наезды на контору тут в общем-то смешны.

В четырех предыдущих местах работы мне встречались похожие проблемы: то необходимость переподнимать регулярно падающий headless libreoffice, то останавливать Jira-сервис при наличии рядом запущенного второго, то опакеченный убунтоидами jenkins, который при удалении deb-пакета смело гасит все процессы, которые может нагрепать по слову jenkins (угадайте, сколько их может быть).

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

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

Ну и чем можно заменить systemd, чтобы посвежее и поудобней?

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

Я просто оставлю это здесь

А я это: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=systemd

И не забудьте про: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

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