неплохо бы иметь прям в гуях системд

в гуях? ты меня пугаешь...

ну то есть

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

малоинформативно будет мониторить статус сервиса в systemd, лучше мониторить сам сервис (ну который программа), типа спрашивать в порт или сокет что-то и ожидать «рабочего» ответа.

надо и то, и то.

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

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

Подсказка: докер с системой мониторинга (любой, жирножаба не обязательная) взлеатет на домашнем компе точно так же, как на продакшене

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

куда ты с подводной лодки (RHEL7) деваешься то

называй systemd сервис

но это раскладку переключать же. я подумаю.

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

куда ты с подводной лодки (RHEL7) деваешься то

я пока еще на RHEL6 до 2020... так скорее «куда ты с подводной лодки (RHEL8) денешься-то?» - вот это вопрос, над которым я сейчас думаю...

:)

я когда еще работал в одной хм... крупной конторе, наоборот всем промывал мозг над переходом на systemd и rhel7

потому что эти, *****, гении, простите за мой французский, сразу же начали писать запускалку сервисов из веб-панели мониторинга, которая самописному агенту на хосте (написанному на java) передавала с помощью протокола jmx (горите в аду, в джаве уже миллион лет http делается в 1 строчку), передавался баш-скрипт для запуска сервиса

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

я говорю - бло, чуваки, то что вы хотите называется ansible+systemd и оно уже написано. Нет, не хотим использовать хорошие вещи, хотим есть говно. И это разработчики?

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

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

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

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

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

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

так ты можешь в своей системе проксировать вызовы скриптов в вызовы системд

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

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

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

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

так ты можешь в своей системе проксировать вызовы скриптов в вызовы системд

че-то я пытался следовать за твоей мыслью, но в итоге сломался и не понял, имеет это какой-то смысл для меня или нет:)

когда наступит 2020 год, у меня будет сразу куча дела: а) систему контейнеров придется менять, б) образ внутри тоже. в) обвязку.

так я и на OpenBSD могу переехать:))) проблема только одна. такой стабильный ABI, как RedHat, не обещает никто:(((

и кстати насчет cron. у systemd же есть своя реализация крона? timers вроде как. я пока вижу только одну их готовую фишку, которую мне пришлось делать через wrapper. RandomizedDelaySec. не слишком богатое улучшение за 20 лет. а все остальные юзкейсы (тот же мониторинг) всеравно пришлось бы делать вручную.

с systemd еще одна проблема. эта их пресловутая совместимость с legacy, которой они прикрываются, как фиговым листком. у меня недавно на тест с федорой прилетел апдейт (видимо, поменяли service-файл) и named запустился с двумя разными -c config значениями. одно было взято из legacy файлов, другое новенькое. и сервис сломался. во веселуха!

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

system-root вот пишет, что у меня какой-то legacy service-file. приехали... теперь я должен не только изучить всю работу systemd, но и проверить, нет ли где конфликтов с legacy...

Нет, не хотим использовать хорошие вещи, хотим есть говно. И это разработчики?

собственной персоной :D других нет

так ты можешь в своей системе проксировать вызовы скриптов в вызовы системд

получается, это не лучший способ. см. выше про legacy.

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

курсы задавания ответов

Спасибо, но нет.

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

хороший вопрос, нужно конкретную штуку тестить, с RefuseManualStart например или ConditionPathExists.

для меня фактически это бы значило переписывание bash-скрипта в формат ini файлов systemd. фактически сервис-файл в моем задании на засыпку содержит куски старых bash скриптов федоры.

есть защита от повторного запуска?

Из коробки же c type=oneshot. Если ты делаешь start если уже запущено, оно же ничего не делает.

Ответ: Если попортить конфиг, то rndc reload тихо свалится, kill -HUP ничего не скажет и пользователь будет думать что релоад был, а его не было

С примером юнита на nginx.org то же самое было, там был просто kill -HUP

Уже поправили

Было: https://web.archive.org/web/20180318051419/https://www.nginx.com/resources/wi...

Стало: https://www.nginx.com/resources/wiki/start/topics/examples/systemd/

[Unit]
OnFailure=notify-failed@%n.service

Вполне себе коллбек. Хотя мало, да

Ответ: Если попортить конфиг, то rndc reload тихо свалится, kill -HUP ничего не скажет и пользователь будет думать что релоад был, а его не было

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

Что к этому можно еще добавить, так это сбивающее с толку сообщение systemd

Aug 20 03:30:56 dell.inter systemd[1]: Reloaded Berkeley Internet Name Domain (DNS).

Это сообщение сгенерировано systemd и не имеет отношения к правде. Потому как в полных логах у нас вот что:

Aug 20 03:30:56 dell.inter named[31699]: reloading configuration failed: unexpected token
Aug 20 03:30:56 dell.inter systemd[1]: Reloaded Berkeley Internet Name Domain (DNS).

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

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

и не имеет отношения к правде

почему не имеет то, если это правда.
и вообще, засунь в престарт named-checkconf

да мне не надо ничего засовывать, как ты не понимаешь) я вас проверить хотел:) ты же сам не понял фишки.) и другие не поняли, что kill -HUP всегда вернет 0, а сервис может быть поломан нафиг. зато systemd пишет, что перезагрузила)

ты опять начинаешь? ещё раз: причём здесь systemd? ты никогда не видел ExecReload=/bin/true? ты вообще не отличаешь работу сервиса и работу системы которая обеспечивает запуск этого сервиса?
всё что после знака = — это не относится к systemd и может делать rm -rf /* и взрывать ядерную бомбу. никого не волнует.

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

зато systemd пишет, что перезагрузила)

Развей мысль еще дальше. Если сделать systemctl nginx reload, то все ошибки пишутся, если сделать systemctl reload named, то нет. Вывод: ПОТТЕРИНГ КОПАЕТ ПОД БИНД И СКОРО В СИСТЕМД ВСТРОЯТ ДНС СЕРВЕР!

как рассказы обо мне относятся к вопросу «причём здесь systemd?», который тебе был задан два раза?

какая команда была выполнена и каков был результат

Была выполнена команда - «убить всех человеков», но как это обычно бывает с системд сдохли все тараканы в Замунде.

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

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

ты же сам не понял фишки.) и другие не поняли

просто ты походу на своей волне. особенной.

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

ExecReload есть, не тупи, значит это и выполнилось. если нет, то будет остановка и запуск.

нет. не выполнилось. нет никакой остановки и запуска не будет.

нет. не выполнилось

почему не выполнилось то, если это выполнилось?
реально блин, ты походу не различаешь вообще состояние systemd сервиса и состояние named.
для тебя похоже выполнение ExecReload это именно изменение состояния %mydeprecated_name.exe%, а не выполнение того, что написано после равно у ExecReload

мне просто интересно, как любители systemd на самом деле в нем шарят

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

для тебя похоже выполнение ExecReload

неправильно написал, какой нафиг ExecReload, это слишком хардкорно. systemctl reload, чтобы даже не знать, что там под капотом.

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

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

А что, в 6 центоси/рхеле будет по другому? Там ведь точно также вернется 0 и напишет что перезагружено.

да мне пофигу

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

комадна в ExecReload вернула 0, с точки зрения systemd reload выполнился корректно, как он еще узнает что что-то не так, через libastral?