root в ядре и обрушение системы через systemd (local)

я очень хорошо знаю твой стиль администирования

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

по факту

По факту ты тут трындишь на ЛОРе. «На словах ты Лев Толстой…»

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

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

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

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

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

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

Вы ничего не путаете?

Один ты уникален, конечно.

В таком случае твой стиль администрирования я тоже прекрасно знаю. YOLO-style вытиранов юникса, которые херачат happy case в башлапше без какого-либо анализа результатов, без наблюдения за системой, без ничего. В лучшем случае где-то там стоит сраный заббикс, который пингует систему раз в минуту «пингуется — ну и за*бись».

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

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

потому что не умеешь писать скрипты?

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

Один ты уникален, конечно.

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

В таком случае твой стиль администрирования я тоже прекрасно знаю.

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

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

а как скажется на SLA этих сервисов твое решение? есть у тебя SLA, по которому ты работаешь? и ты «чтобы было лучше» снижаешь доступность сервисов, которым просто «повезло» оказаться на той же машине? умно!

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

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

Писец аргумент. У нас рухнул httpd на 148-ом сервере, для решения этой «непредвиденной проблемы» надо срочно всю серверную отправить в ребут по питалову. Не, ну а че? У нас тут ынтерпрайз или где?

Если произошло неожиданное и ни на каком уровне ниже эта проблема не была отловлена — то да, нужно отправить всю серверную в ребут по питалову. А потом уже разбираться. Потому что SLA.

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

Я умею писать скрипты.

а зачем спрашиваешь, как контролировать коды возвратов?

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

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

тебя стандартизация привлекает. ты хочешь действовать по известному пути, чтобы не допускать новых ошибок. похвально. но сам механизм скриптов здесь не виноват. он дает гибкость, а ты хочешь все свести к one true way (как в windows). я о том и говорю. я очень хорошо знаю этот способ администрирования. он ни разу не линуксовый изначально.

Если произошло неожиданное и ни на каком уровне ниже эта проблема не была отловлена — то да, нужно отправить всю серверную в ребут по питалову. А потом уже разбираться. Потому что SLA.

Всё, занавес. И эти люди будут запрещать....

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

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

а зачем спрашиваешь, как контролировать коды возвратов?

Потому что ты не вдупляешь, что в рамках *sh нельзя, например, отловить код возврата программы из середины конвейера. И если ты где-нибудь обрабатываешь маунты в цикле и у тебя какой-нибудь xargs упал, потому что длина командной строки больше 2 гигабайт — то хрен ты это отловишь. И скрипт радостно пойдёт, скажем, прибивать rootfs.

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

Да. Потому что я видел, как написан systemd, и видел, как написаны чужие скрипты.

Зато я решаю задачу. А ты её не решаешь, у тебя YOLO «авось ничего не развалится».

ты решаешь задачу, но очень неэффективно.

Неэффективно, зато эффектно. А то может кто ещё не в курсе, что у него что-то там упало.

Зато я решаю задачу. А ты её не решаешь.

С чего ты взял? Мне тоже платили за решение.

Потому что ты не вдупляешь, что в рамках *sh нельзя, например, отловить код возврата программы из середины конвейера.

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

Зато я решаю задачу.

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

«авось ничего не развалится».

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

Неэффективно, зато эффектно.

да уж:) я очень смеялся вчера:

root в ядре и обрушение системы через systemd (local) (комментарий)

Зато я решаю задачу. А ты её не решаешь, у тебя YOLO «авось ничего не развалится».

Решая вашу задачу, вы заодно создаете проблемы другим задачам. Понимаю, к сожалению «варианты лес рубят, щепки летят» не редки.

я чувствую, если буду опять выходить работать в IT, то пойду в какой-нибудь банк на солярис. это windows-безумие, которое покорило Linux, уже не для меня.

это windows-безумие, которое покорило Linux

Ну все-таки пока не полностью.

Мне тоже платили за решение.

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

Personal insults work both ways.

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

Вот у тебя постоянно в аргументации встречаются мифические хорошие скрипты, в которых нет багов и которые не ломаются. Но хороший монолитный код на Си тоже не ломается. Только видишь ли, в чём проблема: кода без багов не существует. Ломаются мои скрипты, твои скрипты, дистрибутивные скрипты, systemd, ядро линукса.

Разница в том, что когда ломается systemd, он это замечает и детерминистично уходит в ребут (а может, кстати, и не уходить, может просто останавливаться и система превращается в sysvinit — это всё настраивается). А когда ломаются скрипты, ты этого не замечаешь.

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

мне проще контролировать, чтобы не развалилось за счет KISS

Только ты не контролируешь. Тебе кажется, что ты контролируешь.

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

у меня свои SLA, которым это должно соответствовать

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

Вот у тебя постоянно в аргументации встречаются мифические хорошие скрипты, в которых нет багов и которые не ломаются.

У меня перед глазами один проект 2003-го года рождения, в нем небольшую часть написал мой друг.
Баш скрипты: ужас конечно по стилю, но за всю историю, багов не обнаружено.
Код на Ц: последний( по времени) баг исправлен 17 февраля сего года.

Если systemd из-за бага ребутнёт машину, это пойдёт в счёт SLA.

Ага, а до ребута там предположим недельку, что-то замудреное считалось. И из-за этого гребанного ненужнод, начинаем всё сначала. Очень удобно.

а может, кстати, и не уходить, может просто останавливаться и система превращается в sysvinit — это всё настраивается

ну и зачем он тогда вообще нужен?

Я правильно понимаю, что у тебя «аргумент» вида

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

Неправильно.

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

SLA

100%

Чот поржал

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

Например что бы посмотреть как оно там считается. Подойдет?

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

Тут такое дело, если это разовая задача, смысл писать к ней морду? Только пустая трата времени. И даже если многоразовая/эпизодическая, но исключительно «для себя любимого». Например какой мне смысл писать морду для задачи которая что-то возьмёт в БД, посчитает и результат положит в БД или в какой-нибудь файлик?
Или если она только на уровне субд крутиться, в редким контрольным выхлопом.
Старое доброе погромиское, прогрессбар таки тоже жрет ресурсы и чем точнее подсчет прогресса, тем больше накладных расходов. Поэтому редких выхлопов, вполне достаточно, только что бы понимать, что оно не зависло, а всё еще работает.

Только ты не контролируешь. Тебе кажется, что ты контролируешь.

Просто с пропатченными мозгами ты не можешь это представить. Нет, я контролирую. Используя доступные мне средства и соблюдая SLA. Когда-то была система контроля конфигов cfengine. Ее авторы, как и ты, были большими теоретиками. Писали про контракты и контролируемые состояния. Пользоваться было невозможно, слишком велики затраты. Потом появился ansible без всяких теорий. Админы быстро его освоили.

«Пингуется — и за*бись». А если кривые скрипты не запустят какой-то процесс...

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

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

В том-то и дело. Полагаясь на systemd, ты забываешь, что никакой софт не может учитывать всего. Так было, когда systemd снес данные чьей-то базы в shm. Кастомные чеки работаю там, где критично, хотя и требуют отладки.

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

Как и со всяким языком, чем ниже порог вхождения, тем больше некачественного кода. Так, как с PHP, например. Но. Это не отменяет тот факт, что для более сложной логики мы берем python или любой другой подходящий инструмент. Если мы хотим спроектировать систему под наши требования, у нас есть гибкость. А ты хочешь действовать по твердой инструкции из MSDN и если произошло что-то непредвиденное, то ты огребешь в 10 раз больше проблем. Вместо простых действий по исправлению, ты будешь ребутать весь ДЦ. В Windows, как ты помнишь, все эти манагеры давно написаны именно в таком ключе. Вообще я думаю, что Microsoft way тебе по многим параметрам должен казаться близок.

Скрипты - это всего лишь клей. Кто-то все делает на клею. Я стараюсь намазывать тонким слоем между известными компонентами. Расширять возможности того же zabbix, например.

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

Просто с пропатченными мозгами

Опять пошли личные оскорбления.

Полагаясь на systemd, ты забываешь, что никакой софт не может учитывать всего.

А ты хочешь действовать по твердой инструкции из MSDN и если произошло что-то непредвиденное, то ты огребешь в 10 раз больше проблем. Вместо простых действий по исправлению, ты будешь ребутать весь ДЦ. В Windows, как ты помнишь, все эти манагеры давно написаны именно в таком ключе. Вообще я думаю, что Microsoft way тебе по многим параметрам должен казаться близок.

Ты придумал себе глупого оппонента и победоносно с ним сражаешься. Нет, я не забываю, не «действую по твёрдой инструкции из MSDN» и не ребутаю весь ДЦ вместо простых действий по исправлению.

Расширять возможности того же zabbix, например.

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

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

«Не видел, но осуждаю»

у тебя всегда я что-то предумываю.:( один ты д'артаньян.

«то да, нужно отправить всю серверную в ребут по питалову.»

root в ядре и обрушение системы через systemd (local) (комментарий)

сейчас скажи, что тебя не так поняли.:(

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

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

будет гораздо надёжнее, чем одна машина с systemd.

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

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

Передо мной все пути.

ага, точно также, когда ты не смог очистить лог на сервере%)

А ты со своим сертификатом по заббиксу

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

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

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

ага, точно также, когда ты не смог очистить лог на сервере%)

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

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

Кто сказал? Если долго повторять свою фантазию, она не станет более истинной.

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

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

В какой ещё конфигурации по умолчанию? Нет никакой конфигурации по умолчанию. Я проектирую свои системы грамотно.