systemd 249

то ЧЕМ и КАК и ЧТО ты будешь исправлять?

emergency shell, debug shell.

А читающему значит не дано понимать зависимости?

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

В моем случае, о котором я упомянул (встречался в сюзе), понадобилось просто исправить fstab

При проблемах в fstab ты загружаешься в emergency shell и смотришь journalctl, где видишь проблемы с fstab.

которые можешь решить и ты

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

Видишь – ты просто посмотрел в скрипт и уже видишь даже потенциальную проблему. Значит считай она решена, буде она иметь место.

Проблема решена не будет, как видно из практики. Даже если ее решат, никакой наглядности в скрипте не останется, будут сотни и тысячи строк fork и wait.

А что с systemd?

А там этой проблемы нет и не будет by design.

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

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

При проблемах в fstab ты загружаешься в emergency shell

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

У меня есть сервис, в котором логирование сделано максимально просто и топорно – вызовом функции printf

А зачем? Чтобы в очередной раз героически решать проблемы, которые ты сам себе не менее героически создал? Или потому, что его писал детсадовец, который про системы логгирования в unix ни сном ни духом?

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

Речь о том, что у systemd нет ни одного реального «преимущества». Потому что цветной синтаксис в журнале это не преимущество. И графон с зависимостями это не преимущество – это вообще не профильные абилки; таким вообще должны заниматься отдельные тулзы: и расцветкой журнала – кому она нужна, – и рисованием зависимостей – если кого этот графон интересует. И между такими тулзами должна быть конкуренция, тогда в дистры пойдут лучшие из лучших тулз.

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

Думаю, я не доживу до дней когда увижу слаку такой. На мой век хватит и аминь.

Ибо простота равна надежности, при всех прочих равных.

Все про «надежность» уже стало понятно, можно не продолжать.

Так что любая программа таки ДОЛЖНА быть предельно простой.

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

А значит «тупому админу» не дано знать зависимости сервиса, если уж он берется писать скрипт его запуска?

Админу дано, а вот системе не дано. Юниты дают эту информацию системе.

Я так понимаю, systemd имеет помимо прочих фишек презупцию того, что пользователь и админ – идиоты

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

Если тебя устраивает такое отношение со стороны разработчиков systemd и их забота о том, чтобы ты себе пальцик не порезал…

Ну вот, переходишь на личности и пытаешься взять на «слабо». Может, все же по теме будем вести обсуждение?

Касательно тезиса: не хочу резать пальцы, хочу работающую и расширяемую систему инициализации.

А зачем нет, особенно, если это решает все проблемы?

Во-вторых, сейчас в клауде так гораздо удобнее.

Я вот вообще тоже склоняюсь к тому, чтобы не использовать spdlog. fmt::print одного более чем достаточно.

Все про «надежность» уже стало понятно, можно не продолжать.

Понятно что тебе нечего в ответ булькнуть и базовая логика неумолима?

а вот системе не дано.

какой системе? systemd? Я разве не только что говорил, что systemd порождает сам те самые проблемы которые «решает»?

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

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

Может, все же по теме будем вести обсуждение?

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

Аминь.

Речь о том, что у systemd нет ни одного реального «преимущества».

Я уже писал, и напишу еще раз. Зависимости между сервисами передаются системе, которая на основе этих зависимостей строит граф задач, который затем исполняет. Не ты этот граф строишь, а система. Не ты рыскаешь по манам и в интернете в поисках информации, выписываешь зависимости и думаешь, в какой последовательности тебе что запустить, fork’аешь и ожидаешь, и ловишь баги в свой лапше, а система, которая уже отлажена. Если в ней что-то не так, то это на 99.9% проблемы некорректно написанного юнита, и эти проблемы легко отловить, потому что доступно большое количество информации и инструментов.

Мне это напоминает про фотошоп современный, который больше иных ОСей. Ибо он заточен на дэбилов. В нем включены все возможные «волшебные кнопки», на каждый случай жизни, которые нужны 0.001% проценту пользователей а втыкают их всем и каждому.

А ты фотошопом-то пользовался? Я вот пользовался, и с уверенностью скажу, что 3/4 кнопок в основном окне программы очень даже активно используются.

А зачем?

Затем, что сделать перенаправление в файл и не изобретать велосипеды это и есть unix-way, в который не умеют все эти допотопные системы инициализации.

Понятно что тебе нечего в ответ булькнуть и базовая логика неумолима?

Ты сам скинул кривую портянку, и теперь меня упрекаешь в отсутствии аргументов?

какой системе?

Твоему материнскому процессу со скриптом.

Поверь, в дистрах без systemd такой сложности нет.

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

Я уже писал, и напишу еще раз

Ок, ценю твердолобость.

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

Тоесть ты благодарен systemd что он сам решает большую часть тех проблем что создал, а не взвалил все из них на тебя?

А ты фотошопом-то пользовался?

Ага. Я остановился и стоял на версии 7.0 когда актуальной была уже версия cs3, тоесть 13. Это потому, что ничего принципиально нового с 7-ки в нем не появилось. Одни волшебные кнопки для инвалидов – до сих пор спавнятся как плесень. Вот почему я уважаю GIMP и linux-way – потому что лет десять работал с фотошопом профессионально, и видел, к чему и как он пришел. Вообще виндой весьма сыт, и не понимаю тех, кто с энтузиазмом воспринимает мутацию линукса в винду, прежде всего под влиянием трояна тысячелетия, под названием systemd

emergency shell, debug shell

Дооооо… Ты сам-то пробовал? Видел, что твой любимый journalctl тебе напишет что-то вроде «ошибка монтирования корневого раздела»? И всё лишь потому, что /etc/fstab «испортился». Совсем. Весь. Но догадываться ты об этом будешь сам, предварительно побаловавшись с e2fsck и прочими инструментами.

И какие проблемы это решает: Централизованное хранилище логов? Хранение на другом узле? Оповещение заинтересованных лиц в мессенджер/SMS? Как простой вывод на экран это всё делает, расскажи.

Все эти проблемы решает тот кто читает stdout,stderr твоего приложения.

Затем, что сделать перенаправление в файл и не изобретать велосипеды это и есть unix-way, в который не умеют все эти допотопные системы инициализации

Даааа…. Ну, как дойдёте до задач, которые давным-давно успешно решал банальный syslog и надумаете изобретать очередной journalctl v.1000478634785 - напишите. Может я к тому времени ещё буду недостаточно стар, чтобы понять, в какой файл надо перенаправить вывод stdout чтобы он переслался в SMS, например.

За логирование в смс надо увольнять.

Т.е. надо написать ещё одно приложение, которое будет мониторить stdout,stderr этого детсадовского поделия (которое с какого-то перепугу стало МОИМ, хотя в прошлом посте работало У ТЕБЯ) чтобы решить проблемы, которые решили лет 40 назад путём создания стандартизованной системы логгирования только потому, что этот самый детсадовец про них ничего не знал?

Эксперты systemd в своём репертуаре…

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

Эта «стандартизованная система логгирования» (де-факто конечно же это не так) создает проблем больше чем решает.

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

Т.е. надо написать ещё одно приложение, которое будет мониторить stdout,stderr этого детсадовского поделия (которое с какого-то перепугу стало МОИМ

Это называется Unix-way…

«ошибка монтирования корневого раздела»

При такой ошибке fstab – одно из наиболее очевидных мест для проверки.

Но догадываться ты об этом будешь сам, предварительно побаловавшись с e2fsck и прочими инструментами.

Как баловавшийся с e2fsck сообщаю: диагностика e2fsck довольно однозначно укажет, что проблема не в фс. Так как проблема в монтировании, то логично проверить место, в котором я указываю, как монтировать фс. Этим местом является fstab.

А ты сейчас про кого? Сислог или самопал? В первом случае, в чем принципиальное отличие? Сидит такой же демон, который читает из дескриптора и куда-то складывает. Во втором случае как ты все перечисленное реализовал?

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

Некоторые разработчики оградили от таких убогих утилитами типа sudoedit и похожая для крона. Но не везде применимо. Хотя systemd, надеюсь, тоже неспроста имеет отдельный daemon-reload.

Пусть так, всё равно понять что такое syslog, как оно работает и причём тут unix-way экспертам systemd не дано….

Вы мне ответьте, почему вы printf используете? Ведь это же не unix-way’но. Надо запилить собственную функцию вывода.

Как баловавшийся с e2fsck сообщаю: диагностика e2fsck довольно однозначно укажет, что проблема не в фс

Да ты что?! Правда чтоли? А время, которое ты потратил за запуск и анализ выхлопа e2fsck тебе кто вернёт? Поттеринг?

Так как проблема в монтировании, то логично проверить место, в котором я указываю, как монтировать фс

С чего вдруг? Может у тебя /sbin/mount окочурился?

Пусть так, всё равно понять что такое syslog, как оно работает и причём тут unix-way экспертам systemd не дано….

Какое отношение к логу в приложении имеет systemd?

Вы мне ответьте, почему вы printf используете? Ведь это же не unix-way’но.

Очень даже unix-way’но.

А время, которое ты потратил за запуск и анализ выхлопа

10 минут? Жаль, конечно, но и fstab не каждый день наворачивается.

С чего вдруг? Может у тебя /sbin/mount окочурился?

Правки в /sbin/mount кривыми ручками не вносятся, в отличие от fstab. Это допустимо, но вариант с fstab многократно вероятнее.

Я - про syslog и даже, чёрт с ним, systemd journal.

В первом случае, в чем принципиальное отличие? Сидит такой же демон, который читает из дескриптора и куда-то складывает.

Он есть, умеет, отлажен, работает. Уже есть. Уже работает. У него только один фатальный недостаток…

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

А зачем у меня это спрашивать? Это у Reset такая гениальная система логгирования, которая printf’ом логи пишет непонятно куда. У него и спрашивай, какими костылями он это огородил.

Какое отношение к логу в приложении имеет systemd?

Эксперты systemd такие эксперты, даже самого systemd не знают…

man systemd-journald.service

Очень даже unix-way’но

Уже существующий printf - unix-way’но, уже существующая система логгирования - не unix-way’но. Трудно быть шизофреником, понимаю.

10 минут? Жаль, конечно, но и fstab не каждый день наворачивается.

Я не спрашивал, жаль тебе или нет, я спрашивал, кто тебе их вернёт. Так кто?

Правки в /sbin/mount кривыми ручками не вносятся, в отличие от fstab

Правильно, они вносятся прямыми. zypper dist-upgrade например.

man systemd-journald.service

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

Я не спрашивал, жаль тебе или нет, я спрашивал, кто тебе их вернёт. Так кто?

Кто тебе часы переписывания портянок вернет, клоун?

Правильно, они вносятся прямыми. zypper dist-upgrade например.

Вот и славно, что прямыми. Тем больше уверенности в том, что смотреть нужно fstab.

Еще раз, какое отношение журнал systemd имеет к логу в приложении?

Приложение может в него писать.

Почему приложение должно завязываться на journald или syslog?

Потому же, почему оно завязывается на printf.

Кто тебе часы переписывания портянок вернет, клоун?

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

Тем больше уверенности в том, что смотреть нужно fstab

С какого счастья при обновлении БИНАРНИКОВ надо смотреть текстовый КОНФИГ? Который: а) при предыдущих обновлениях не менялся никогда, б) если какие-то конфиги переписываются - zypper плюнет в консоль минимум warning в) из сообщений «божественного» journalctl ровно НИКАК не следует, что с fstab хоть какие-то проблемы имеются.

Потому же, почему оно завязывается на printf.

Невозможно «завязаться» на printf, реализация этой функции есть везде – в отличие от syslog/journald и др.

С какого счастья

Попробуй почитать сообщения, на которые ты отвечаешь.

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

И я понимаю был бы какой-нибудь структурированный логгер, от которого есть какой-то профит при анализе логов (да, тот же journald или wpp/etl на оффтопике). Но формат сислога ж достаточно убог.

Или вот этот костыль с sighup…

Haters gonna hate

Невозможно «завязаться» на printf, реализация этой функции есть везде

4.2. BASIC, Pascal, C#, Python - нету.

Попробуй почитать сообщения, на которые ты отвечаешь

Понятно, почему при изменении бинарников надо смотреть текстовый конфиг - известно только Поттерингу и его почитателям. Какие ещё у вас есть откровения? Когда комп вырубается по kernel panic: out of memory надо проверять вентилятор?

И я понимаю был бы какой-нибудь структурированный логгер

Это printf «структурированный логгер» чтоли?

Но формат сислога ж достаточно убог

В journal используется классификация уровней ошибок:

0 — EMERG (система неработоспособна);
1 — ALERT (требуется немедленное вмешательство);
2 — CRIT (критическое состояние);
3 — ERR (ошибка);
4 — WARNING (предупреждение);
5 — NOTICE (всё нормально, но следует обратить внимание);
6 — INFO (информационное сообщение);
7 — DEBUG (отложенная печать).

Уровни логгирования syslog в порядке уменьшения важности: emerg - Система в панике. Сообщения немедленно выводятся на все активные терминалы. Продолжение работы невозможно. alert - Система может продолжить работу, но эту ошибку следует устранить немедленно. crit - Это критические ошибки, такие как проблемы с аппаратным обеспечением или серьезные нарушения работы программного обеспечения. err - Разнообразные ошибки. Такие ошибки должны быть устранены, но они не разрушат вашу систему. warning - Предупреждения. notice - Общая информация которая должна быть записана, если она вам нужна, вероятно она не потребует вашей реакции. info - Различная системная информация. debug - Отладочные сообщения могут содержать всю информацию которую счел необходимым вывести ее разработчик для отладки кода. none - Специальный уровень означающий - <ничего не записывать в данной категории>.

Какой стройный структурированный journal! И какой убогий syslog!

Эксперты systemd прям эксперты…

4.2. BASIC, Pascal, C#, Python - нету.

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

Это у Reset такая гениальная система логгирования, которая printf’ом логи пишет непонятно куда.

Приложению не положено знать куда она оно пишет свои сообщения. Разгребать это – ответственность других слоев. Всё по Unix Way. У меня в итоге все попадает в «хадуп»-like систему и можно «грепать» это с помощью обычного sql.

Решил клоуна включить?

Зачем мне его включать? Ты и так здесь.

Есть другие стандартные функции для печати сообщений в стандартные потоки

Чего? Какие «другие»? Было сказано однозначно: «реализация этой функции есть везде». К тому же в том же самом C# Console.Write[Line] - это НЕформатированный вывод, а printf - форматированный. Эксперты systemd, вы вообще хоть что-то знаете?

Приложению не положено знать куда она оно пишет свои сообщения

И именно поэтому у него есть stdout и stderr. А в сокет надо писать почему-то через send, а не через printf. Не, приложению совершенно точно не положено знать, куда оно пишет… «Когда вы говорите, Иван Васильевич, впечатление такое, что вы бредите»(с)

🤯🔫

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

Клоун, ты даже не стараешься.

Так как проблема в монтировании, то логично проверить место, в котором я указываю, как монтировать фс

С чего вдруг? Может у тебя /sbin/mount окочурился?

Правки в /sbin/mount кривыми ручками не вносятся, в отличие от fstab. Это допустимо, но вариант с fstab многократно вероятнее.

Правильно, они вносятся прямыми. zypper dist-upgrade например.

Вот и славно, что прямыми. Тем больше уверенности в том, что смотреть нужно fstab.

С какого счастья при обновлении БИНАРНИКОВ надо смотреть текстовый КОНФИГ? Который: а) при предыдущих обновлениях не менялся никогда, б) если какие-то конфиги переписываются - zypper плюнет в консоль минимум warning в) из сообщений «божественного» journalctl ровно НИКАК не следует, что с fstab хоть какие-то проблемы имеются.

Т.е. ты настолько безмозглый, что даже не можешь внятно объяснить, почему надо смотреть в конфиг, хотя ДВЕ программы, которые работают с ним, ничего про это не сказали, но я клоун? Это работа с systemd так мозг разжижает? Или ты предавался половым утехам с Поттерингом и он тебя заразил чем-то?

Клятiй redhat ломает наш зоопарк несовместимости!!111ОДИНОДИНОДИН

И не говори - столько народа было при деле, ковырялись там в чём-то коричневом, изображали из себя сисадминов, гордо выпячивая впалую грудь… А теперь лафа закончилась - надо либо читать документацию и работать, либо идти на ЛОР выплёскивать полыхающие обиды. Какой выбор делают недоумки - мы можем регулярно наблюдать в комментах.

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

Не льсти себе - твоя позиция разве что в маргинальном баттхёртиане возобладала.

Вот сколько читаю комментарии, не могу никак понять, почему противники системд расписываю целые аргументированные портянки, а вот любители системд ограничиваются простым и кратким «вы просто ничего не понимаете, идиоты»?