вопрос на засыпку по systemd

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

Можешь порадоваться, что они нашли время позаниматься с тобой бэбиситтингом.

используя рецепты из старых init скриптов. сервисы ведь работали перед этим годами

А в sysv или upstart такая конструкция как-то по другому будет работать? Она ж ведь точно так же 0 вернёт?

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

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

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

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

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

убаюкивающего лог сообщения, которое полезной нагрузки не несет

убаюкивающего
апологеты systemd просто не распарсили то, что увидели глазками

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

вопрос на засыпку по systemd (комментарий)

вопрос на засыпку по systemd (комментарий)

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

Т.е. косяк в команде перезагрузки, и в других инитах будет так же, но виноват все равно systemd? Потрясающая логика.

не выводила раньше инит система сообщений типа: я все сделала, а что там с сервисом начхать.

tomcat не доводилось запускать?

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

Т.е. косяк в команде перезагрузки, и в других инитах будет так же, но виноват все равно systemd? Потрясающая логика.

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

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

Так суть в том, что инит скрипт тупо дергает другой скрипт, и радостно сообщает, что tomcat запущен, и пофигу, что там с ним на самом деле.

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

С аналогиями у тебя еще лучше, чем с логикой.

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

Который умер в 2014-ом? Твои советы один краше другого.

а раньше можно было просто логи открыть

В sysv конструкция другая.

/usr/sbin/rndc reload >/dev/null && log_end_msg 0 || log_end_msg 1

В случае с tomcat'ом знакомая ситуация; я когда-то писал свой стартовый срипт поэтому. Ну как писал, минут за 15 из skeleton'а сделал. А вот в systemd та же картина. Он дёрнул скрипт, тот молча вернул 0 и никто ничего не проверил. Т.е. профита от смены системы инициализации в данном случае ноль.

И, кстати, в init-скрипте на reload ещё дополнительные проверки настроек сети делаются, чего нет в вышеприведённом юните почему-то.

А не, пардон. Он ожил. Но лучше от этого не стал.

какая команда была выполнена

/bin/sh -c /usr/sbin/rndc reload > /dev/null 2>&1 || /bin/kill -HUP 31699

каков был результат

(code=exited, status=0/SUCCESS)

настоящих колбеков к см нет

man dbus

Ага, точно.:) Это правильный ответ:) rndc reload выходит с ошибкой, а kill -HUP вернет статус 0.:)

А знаешь, почему так? Потому что в твоём дистрибутиве юнит писали дебилы.

named честно уведомил об ошибке, но сообщение это не попало никуда

А знаешь, почему это сообщение не попало никуда? Потому что в твоём дистрибутиве journald интегрировали дебилы.

Итого: в обоих случаях дело в дебилах-интеграторах, но виноват, конечно же, systemd и лично Лёня, просто потому что он всегда виноват.

Это где-нибудь в дебиане? В 6 центоси в инит скрипте та же команда, что и в юните. Т.е. автор юнита перенес как было.

А знаешь, почему так? Потому что в твоём дистрибутиве юнит писали дебилы.

В арче такая же петрушка. И где же тогда не дебилы?

Ну вот про что и речь. Ничего не поменялось, но systemd говно, просто потому что.

А знаешь, почему это сообщение не попало никуда? Потому что в твоём дистрибутиве journald интегрировали дебилы.

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

я там уже писал в ветке про дебиан. LP структурировал хранение логов, а дибилы всеравно sed'ом парсят.

мейнтейнеры используют service файлы, как обертку в виде ini файлов вокруг bash-скриптов. отсюда ошибки.

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

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

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

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

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

Объясните кто-нибудь, зачем вся эта питрасня с || /bin/kill -HUP, дана же control utility, почему нельзя просто

ExecReload=/usr/sbin/rndc reload

man dbus

вот когда яндекс начнет использовать на серверах под нагрузкой dbus, я подумаю.

Почему автор юнита понаписал отсебятины, не знаю.

because we can! потому что ему дали такую возможность! в systemd заявлена совместимым с предыдущими решениями. вот мейнтейнер базового сервиса и скопировал частично(!) то, что было в init скрипте.

В sysv конструкция другая.

/usr/sbin/rndc reload >/dev/null && log_end_msg 0 || log_end_msg 1

самое интересное имхо то, что log_end_msg - это стандартизированная в LSB функция. фактически у нас уже есть стандарт для init скриптов, но systemd всеравно продвигали со словами «bash скрипты это плохо, потому что каждый пишет как хочет».

см. выше, я уже ответил. because we can.

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

я еще раз говорю, я не против универсализации. я бросал в небо чепчик, когда в RHEL6 и Ubuntu 10.04 вышли с похожими версиями ПО (upstart в т.ч.).

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

/usr/sbin/rndc reload >/dev/null && log_end_msg 0 || log_end_msg 1

ExecReload=/usr/sbin/rndc reload

В федоре же. Вот там то все как надо, пшшаудио не шипит, под вяленым все работает даже на невидии а видеопотоками рулит pipewire. А главное btrfs с flatpak обмазан даже bash.

если разобраться, то я готов.

сначала дебиан:

эквивалентен. мы просто передаем LSB-обертке статус выхода, который ничего не сломает и предсказуемо отработает. выхолоп не убивает. '>' перенаправляет только stdout, а не stderr.

дальше я уже слабо начинаю тебя парсить:

Т.о. мейнтейнер бинда в редхате, намотавший ad-hoc логики

я не уверен, какой смысл ты вкладываешь в ad-hoc

фейлит (#bz?) славный малый

что фейлит? казнить нельзя помиловать

потому что не запретил вызов /bin/sh -c

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

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

Абсолютно справедливо.

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

Совершенно верно. Я не знаю, как можно утверждать обратное.

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

Почему «вдруг начали»? Мейнтейнеры лажали всегда, сколько помню. В systemd налажать сложнее, но некоторым деятелям всё равно удаётся.

мейнтейнеры используют service файлы, как обертку в виде ini файлов вокруг bash-скриптов.

А виноват systemd, да? Если бы обёртки не было, bash-скрипты начали бы работать лучше?

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

А какая разница, в каком он формате? Важна семантика, а не синтаксис. Семантика юнитов systemd простейшая (если не вдаваться в подробности, которые важны трём с половиной низкоуровневым землекопам).

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

У меня никакой задачки не было. Я здесь «неофициальный русскоязычный саппорт systemd», и мой ответ — NOTOURBUG. А задачка была у того, кому работодатель платит. А платит он за то, чтобы ты изучил работу системы, сделал тестовое развёртывание, починил баги по результатам и так далее. Не изучил — поимей проблемы.

А ты не замечаешь разницы между «универсальное решение, которое сделает использование разных дистров похожим» и «сравниваем сервис файлы из разных дистров»?

systemd продвигался как универсальный интерфейс между админом и машиной. И с этой задачей он справился на 100%. Я сейчас могу подойти практически к любой машине, сказать systemctl status postgresql и мне покажут запущенные процессы, сколько он отжирает памяти, высокоуровневое состояние и выдержку из лога. И это офигенно.

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

ППКС

А я не говорил, что где-то есть недебилы. Кстати, я действительно удивлён, что в арче такая же лажа (на самом деле немного другая, но не суть). Мне казалось, что у нас мейнтейнеры вменяемые. Возможно, это просто юнит из апстрима?

Мейнтейнеры лажали всегда, сколько помню.

когда последний раз ты переписывал за них sysv init скрипт?

В systemd налажать сложнее, но некоторым деятелям всё равно удаётся.

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

Семантика юнитов systemd простейшая

была бы простейшей, если бы не расширение за счет inline скриптов.

У меня никакой задачки не было.

ну и зря. надо быть уверенней в себе.

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

нет, друг))) за это все тебе могут платить, если ты junior и выполняешь поставленную перед тобой задачу.)) если ты действительно junior или middle тебе платят, чтобы ты сделал тестовое тестирование того, что сказал тебе сделать начальник. не изучил то, что сказал освоить начальник - поимей проблемы) все верно. а если ты senior (с функцией управления) тебе платят не за изучение системы) а за конечный результат.

А ты не замечаешь разницы между «универсальное решение, которое сделает использование разных дистров похожим» и «сравниваем сервис файлы из разных дистров»?

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

когда последний раз ты переписывал за них sysv init скрипт?

Несколько лет назад. С тех пор юзаю systemd и никаких init-скриптов не вижу :)

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

Ничего удивительного. Давно ЛОР стал форумом профессиональных администраторов? :D

была бы простейшей, если бы не расширение за счет inline скриптов.

«inline скрипты» в семантику юнитов не входят. Если ты запустишь из юнита программу на брейнфаке, systemd к этому, опять же, никакого отношения не имеет.

а если ты senior тебе платят не за изучение системы) а за конечный результат.

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

Возможно, это просто юнит из апстрима?

В редхате, по крайней мере, в 2012 году майнтейнер сконвертировал из редхатовского же инит-скрипта как смог https://src.fedoraproject.org/rpms/bind/c/d218af54a5284ff3508ad697176ee8167a0..., перенеся весь дроч || /bin/kill -HUP как есть.

тестовое развёртывание — то херовый из тебя senior.

верно, но платят не за него, пойми:) я могу LFS тестировать. смысл не в этом.

Если ты запустишь из юнита программу на брейнфаке, systemd к этому, опять же, никакого отношения не имеет.

имеет. ты из windows ini файлов программу на брейнфаке запустить можешь?

Несколько лет назад.

и что же было так серьезно поломано? named? nginx?

Ничего удивительного. Давно ЛОР стал форумом профессиональных администраторов? :D

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

обрати еще внимание на точно такие же грабли с nginx:

вопрос на засыпку по systemd (комментарий)

частично перенесенный скрипт работал некорректно.

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

Семантика юнитов systemd — простая. Это означает, что написать сравнительно правильный юнит с нуля — просто. Но это не означает, что любой заранее заданный юнит будет оптимальным и правильным.

intelfx, цитирую твое исправление:

А если ты senior и в твою работу по достижению конечного результата не входит тестовое развёртывание — то херовый из тебя senior.

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

я так понял, ты уверенно хочешь назвать меня плохим senior, но вот причину для этого никак не можешь подобрать) боюсь, что второе исправление выглядит прямо глупо.:Е) нет, начальник тех.отдела не смотрит в unit файлы, он поручает тебе «чтобы все работало». и все:) senior смотрит, если есть проблема, которую junior не смог решить.

верно, но платят не за него, пойми:) я могу LFS тестировать. смысл не в этом.

Я прекрасно всё понимаю. А ты придираешься к формулировкам и хамишь. Впрочем, ничего нового.

ты из windows ini файлов программу на брейнфаке запустить можешь?

windows ini — это формат представления данных. Он не задаёт семантику.

и что же было так серьезно поломано? named? nginx?

Всё было поломано куда серьёзнее. А потерянный статус при релоаде — это же вообще норма.

А тебе, я вижу, очень хочется понтануться тем, что «запускать команды» и «читать юниты» — это всё, мол, грязная работа для жуниоров, о которую ты даже руки марать не хочешь? Судя по ОП, уже замарал. В пределах данного треда на твою карьеру насрать. Здесь обсуждается конкретная техническая проблема.

А ты придираешься к формулировкам и хамишь.

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

Всё было поломано куда серьёзнее.

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

это всё, мол, грязная работа для жуниоров

прости, это единственное объяснение, которое я смог найти для твоей логики. принципиальное выгораживание systemd как самоцели лишено смысла. для меня по крайней мере. это я и пытался тебе объяснить.

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