O
аллергия на говно, что передается по наследству
иди в винду, там повершел, красота
Size: a a a
2020 December 26
DS
И вот опять вы чет от меня добиться пытаетесь. Ну ок, про гарантии. Мне достаточно, что sys v вызовет скрипт, дальше вопрос гарантий на стороне скрипта.
ну вот я и хотел чтобы ты это признал. А гарантировать надежность всех этих скриптов на баше конечно никто не может
t
И вот опять вы чет от меня добиться пытаетесь. Ну ок, про гарантии. Мне достаточно, что sys v вызовет скрипт, дальше вопрос гарантий на стороне скрипта.
ну вот и ответ почему неопределенность присутствует в работе
O
ну вот я и хотел чтобы ты это признал. А гарантировать надежность всех этих скриптов на баше конечно никто не может
интересная логика
1. Свято верить, что systemd точно все сделает правильно
2. Не верить, что баш скрипт все сделает правильно..
1. Свято верить, что systemd точно все сделает правильно
2. Не верить, что баш скрипт все сделает правильно..
t
иди в винду, там повершел, красота
у меня был смежный стек два года, я бы пошутил и послал вас админить кластер монги, но я не настолько злой человек
O
При том, что миллион лет существуют готовые срипты:)
AK
В логике "я просто ставлю какие-то неизвестные пакеты и надеюсь что systemd все разрулит" это единственный рабочий вариант.
Но, как бы так сказать то, а то опять с фанатизмом кинетесь тут доказывать - для меня более естественно, когда процесс старта и остановки четко виден на уровне команд и его можно просто менять, читать и имплементировать любую кастомную логику.
Но, как бы так сказать то, а то опять с фанатизмом кинетесь тут доказывать - для меня более естественно, когда процесс старта и остановки четко виден на уровне команд и его можно просто менять, читать и имплементировать любую кастомную логику.
в sys v было легко и просто дебажить инит скрипты, потому что они написаны на баше. А в systemd такой потребности просто нет.
O
у меня был смежный стек два года, я бы пошутил и послал вас админить кластер монги, но я не настолько злой человек
сразу после того, как вы станете мейнтенером systemd :)
DS
интересная логика
1. Свято верить, что systemd точно все сделает правильно
2. Не верить, что баш скрипт все сделает правильно..
1. Свято верить, что systemd точно все сделает правильно
2. Не верить, что баш скрипт все сделает правильно..
так мне не надо свято верить. Я знаю по докам как он дейсвтует и в зависиомсти от каких настроек. И я точно буду знать что systemd пошлет TERM при остановке процесса В отличии от sys v init.
t
сразу после того, как вы станете мейнтенером systemd :)
но зачем, там и без меня справляются
АГ
ващет есть гарантии. Он совершенно точно TERM пошлет в процесс, также ты можешь сделать так, чтобы он посылал KILL если процесс не завершается. А в sys v init нет гарантий что он вообще хоть что-то сделает с процессом.
То что он пошлёт терм в процесс, не значит, что он успешно завершит его, т.к. процесс может просто блокировать сигтерм. Или уйти в обработчик сигнала на оч долго. Что приведёт к тайм-ауту и принудительному сигкиллу. А сигкилл он отправляет всегда, если не скажешь обратное. Поэтому расчитывать на безгрешность системд без знания того чем он управляет - безумие.
t
ух, мы сейчас обсуждаем почему ssh может не зарестартиться же? Или у кого-то еще кублет не мониторится
O
ух, мы сейчас обсуждаем почему ssh может не зарестартиться же? Или у кого-то еще кублет не мониторится
че?:)
DS
То что он пошлёт терм в процесс, не значит, что он успешно завершит его, т.к. процесс может просто блокировать сигтерм. Или уйти в обработчик сигнала на оч долго. Что приведёт к тайм-ауту и принудительному сигкиллу. А сигкилл он отправляет всегда, если не скажешь обратное. Поэтому расчитывать на безгрешность системд без знания того чем он управляет - безумие.
ну так я про это и говорю. Что ты точно по докам можешь знать как и что он будет делать. В sys v init ты знаешь только то, что ты запустил баш скрипт. И гарантий что он хоть каокй-то Kill сигнал процессу отправит никаких, он может вообще ничего не сделать, а может парсить регулярками из ps и килять или килять другой процесс из-за ошибки в регулярке (что я встречал кстати)
t
че?:)
что вы там гоняете, раз нужно читать 100к строчек кода системд?
АГ
Это оч интересный кейс для нагруженных бд например, про нагружённость которых системд ничего не знает)
O
что вы там гоняете, раз нужно читать 100к строчек кода системд?
чет мне кажется вы неправильно то мое сообщение прочитали. Там речь шла про "когда оно поломается".
t
чет мне кажется вы неправильно то мое сообщение прочитали. Там речь шла про "когда оно поломается".
и когда же, там обратный отсчет есть?
AK
То что он пошлёт терм в процесс, не значит, что он успешно завершит его, т.к. процесс может просто блокировать сигтерм. Или уйти в обработчик сигнала на оч долго. Что приведёт к тайм-ауту и принудительному сигкиллу. А сигкилл он отправляет всегда, если не скажешь обратное. Поэтому расчитывать на безгрешность системд без знания того чем он управляет - безумие.
Везде есть место для разумного компромисса и рассчёта рисков. Безумие - изучать системд досконально, когда нужно просто прочитать доки и написать простой конфиг unit'а
O
и когда же, там обратный отсчет есть?
вы умеете в статистику? или вы просто верите что все будет хорошо?