systemd 251

А можно ссылочку? Я найти не могу

Оригинальное письмо поцтеринга с ходу не нашёл, вот один из «второисточников» с анализом происходящего: https://www.zdnet.com/article/lennart-poetterings-linus-torvalds-rant/ Зная точный текст (там прямая речь), можно, наверное, и сам оригинал отыскать, мне сейчас малость некогда.

Вы подменяете понятия: речь шла о надёжности написанных на shell rc-скриптов, а не самого apache.

Апач состоит не только из собственного основного бинарника, и это, по-моему, довольно очевидный факт. Вот эту вот команду apachectl я и в бытность мою сисадмином в провайдинге (с 1997 по 2000 включительно), и уже после того, простым хоббистом, всегда использовал и до сей поры использую (да, блин, на моих серверах всё ещё «единичка», и плевать я хотел на EOL), а что она представляет собой shell-скрипт – если когда и знал, то забыл. И что-то мне подсказывает, что едва ли не все, кто апача гонял и гоняет, эту apachectl всегда юзали в хвост и в гриву.

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

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

Ну вы ж сами его и откопали.

Я не копал, я только показывал, где копать. Сам копать я бы поленился.

А хотите, я rc-скрипт актуальной версии MySQL прокомментирую? — там всё так же плохо.

И что? Много у кого из-за этого «всё плохо» реально хоть что-то плохое произошло?

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

я принципиально не проверяю, что malloc вернул

И вот этот говнокодер берётся других программированию учить?

И вот этот говнокодер берётся других программированию учить?

(задумчиво) ну расскажи мне тогда для начала, как вот прямо сейчас взять, написать программу с malloc’ом, на реально существующем линуксе её запустить и сделать так, чтоб этот маллок таки вернул сакраментальный NULL. Не, я-то знаю, а вот ты знаешь?

с ходу не нашёл

Я не копал, я только показывал

ну расскажи мне тогда

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

Ага, понятно, за собственные слова отвечать не желаем. Да и не умеем, судя по всему.

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

я тебя давно уже заигнорить собирался

Ты главное не очень вспотей бегая за мной чтобы рассказать как сильно я тебе безразличен. До чего всё-таки жалкое зрелище - тролль которого отказываются кормить :)

Столько текста — и лишь банальный «УМВР»…

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

Поэтому если я вижу, что гонка при конкурентном доступе к ресурсу чинится не одним из стандартных методов (сериализация доступа через мьютексы, атомарные операции…), а каким-нибудь usleep() с комментарием «20 мс должно хватить», то такой сотрудник немедленно отправляется нахрен.

Хватит пропагандировать говнокод, аргументируя «А у меня всё работает и так».

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

Ну и зря. Где-то могут быть другие настройки overcommit, где-то можете упереться в RLIMIT_AS, где-то не влезете в адресное пространство, где-то банально сработает эвристика в ядре при попытке выделить явно больше памяти, чем свободно + swap, а где-то это вообще будет не Linux.

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

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

банальный «УМВР»…

«УМВР» расшифровывается как «у меня всё работает». В данном случае работало не у меня, а у по меньшей мере 90% всего интернета. Разница, по-моему, вполне очевидна.

плавающие баги из-за гонок проявляются не каждый первый и даже не каждый второй раз

Нет, ты таки не понимаешь. Весь твой рассказ сводится к тому, что при остановке (!) апача с помощью apachectl может что-то там проявиться. При этом ты совершенно игнорируешь тот факт, что, во-первых, корректная остановка сервиса вообще-то никому ни в какое место не упёрлась (пристрелить и всё; лично я много раз вообще убирал из /etc/rc?.d/ все ссылки с буквой K, чтобы система ложилась быстрее); во-вторых, что её в реальной жизни делают либо перед перезагрузкой (когда реально пофигу, всё равно все лягут, не тушкой так чучелом), либо вручную (когда тем более пофигу – если что-то пойдёт не так, у сисадмина всегда под рукой животворящая команда kill).

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

каким-нибудь usleep() с комментарием «20 мс должно хватить»,

Это совершенно иная ситуация. Точнее, здесь вообще не описан контекст, в котором это происходит, и, как следствие, можно предположить, что тут возникнет такой race condition, который приводит к эксплойтабельным дырам (да, бывает, да, знаю; да, даже в книжке об этом написал).

то такой сотрудник немедленно отправляется нахрен.

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

Ну и зря. Где-то могут быть другие настройки overcommit,

О, ты хотя бы об этом знаешь :-) Вон свежезаигноренный zabbal явно не знал ничего про то, по каким именно причинам игнорировать значение malloc якобы нельзя, просто когда-то кому-то поверил.

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

где-то можете упереться в RLIMIT_AS,

Это вот более реально, хотя бы ядро пересобирать не надо.

Если вдруг, паче чаяния, это где-то реально проявится (что крайне маловероятно, замечу), то программа вместо «корректного» предсмертного вопля «мне не хватило памяти, прощайте» просто тупо свалится в кору по разыменованию NULL’а с SIGSEGV’ом. Если, опять же, это окажется проблемой, т.е. ну хоть кто-нибудь найдётся, кому такое поведение моей программы помешает в достаточной степени, чтобы об этом заявить, то я одной командой во всей программе заменю вызовы malloc на что-то вроде mallox или malloc1 или mymalloc (вот ей-богу, не знаю, как правильно это назвать), а сам этот mallox будет вызывать malloc, проверять возвращённое значение и при NULL’е вызывать abort, причём, замечу, не говоря ни слова, поскольку выдавать диагностику – не её собачье дело. Всей работы минут на пять, включая пересборку.

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

но для прода это почти всегда недопустимо.

Недопустимо тратить время и силы на борьбу с несуществующими проблемами. Особенно, как в случае с systemd – ЧУЖИЕ время и силы.

я в курсе, что успех malloc() не всегда означает,

Вот даже интересно, то есть ты понимаешь, что в 99,9999% случаев при нехватке памяти программа всё равно свалится по сигналу и без всякой диагностики (не говоря уже о том, что для мало-мальски корректной программы нехватка памяти – событие примерно столь же частое, как падение кирпича с крыши в обычном среднестатистическом городе), но при этом всерьёз требуешь тратить время на «корректную» обработку оставшегося 0.0001% случаев? Нет, вот ты всерьёз это всё?

Ты, дядь, не понимаешь главного. Они не видели другого (а если и видели, то были детьми). Сути процесса не понимают. Почему появилось systemd не знают. Им просто удобно нажать команду и верить, что всё зашибись. Знаний глубоких нет. Как кричат - унификация! Куд-кудах!

Они не видели другого

Да блин, мало ли кто чего не видел, ну башку-то включить не? Вроде неглупые же люди, один вон даже программировать умеет, код на race conditions анализирует, ну где банальный здравый смысл?

я одной командой во всей программе заменю вызовы malloc на что-то вроде mallox или malloc1 или mymalloc (вот ей-богу, не знаю, как правильно это назвать), а сам этот mallox будет вызывать malloc, проверять возвращённое значение и при NULL’е вызывать abort, причём, замечу, не говоря ни слова, поскольку выдавать диагностику – не её собачье дело. Всей работы минут на пять, включая пересборку.

Ещё бы в таком некритическом случае ронять весь сервис вместо отказа данному клиенту и продолжения работы…

Механизм обработки ошибок должен закладываться ещё на этапе проектирования программы. Описанные вами быстрофиксы — это явный признак плохой архитектуры и культуры разработки.

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

Недопустимо тратить время и силы на борьбу с несуществующими проблемами

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

«Ошибка записи в 99,999% случаев выявляется ещё до вызова close() — так зачем тратить время на проверку возвращаемого ею значения?» — именно так думал ваш собрат по разуму, а потом пару дней сидел и разбирался, откуда в базе мусор, хотя в логах чисто.

Весь твой рассказ сводится к тому, что при остановке (!) апача с помощью apachectl может что-то там проявиться.

Пытаетесь подменить предмет разговора? Я написал:

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

В ответ вы заявили:

Писал неоднократно

На что я попросил вас хотя бы привести примеры таких полностью корректных init-скриптов. Вы скинули ссылку на каталог с кучей rpm-ок, скрипты которых я бегло и просмотрел.

Разумеется, оказалось, что в просмотренных скриптах куча проблем в граничных случаях, т.е. мой исходный тезис подтверждён. И теперь вы сменили пластинку на «а эти проблемы не являются существенными, потому что деды их уже 100500 лет используют, и никто не жаловался». 🤦

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

Нет, это просто прекрасно!

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

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

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

Впрочем, в реальной жизни никто никогда не отходит от дефолтного поведения ядра

Ясно-понятно. Спорить с теоретиками, делающими «обоснованные» предположения прямо с потолка, бессмысленно.

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

Ещё бы в таком некритическом случае ронять весь сервис

Слушай, ну это уже не смешно. Какой к дьяволу «некритический случай», если процессу не хватило памяти – он мёртв! Всё! Отдельная обработка спецслучая «тут какой-то дуболом поставил RLIMIT_AS, которого нам не хватило» здесь обойдётся в if после каждого malloc’а и в мучительные размышления «а что делать-то на двадцатом уровне вложенности вызовов» при каждом, опять же, malloc’е. Есличо, malloc в явном виде бывает только в чистом Си, а там исключений не завезли.

Между делом, то, что мы упёрлись в RLIMIT_AS, означает буквально, что данная программа несовместима с данным окружением, т.е. админ создал программе условия, в которых она функционировать не может. Офигенный «некритический случай». И касается это, замечу, всех клиентов, а не одного, то есть отказать одному и надеяться, что с остальными будет всё хорошо, когда мы упёрлись в административный лимит адресного пространства – это какой-то, пардон, карго культ.

Коротко говоря, обработка результата malloc не поможет ничему. Вообще. Совсем. Даже в том 0.0001% случаев. Это просто бессмысленная трата сил.

Ошибка записи в 99,999% случаев выявляется ещё до вызова close()

А я где-нибудь тут говорил, что не обрабатываю возвращаемое значение close? Нет, вот ткни мне пальцем, где я это сказал? Впрочем, верну тебе твой аргумент: неоднократно видел примерно таких же, как ты, упёртых поборников «правильного кода», которые заставляют подчинённых обрабатывать результат close вообще всегда, в том числе и тогда, когда поток открыт read only. Что характерно, они обычно не могут дать внятного ответа на вопрос «и что делать, если всё прочиталось, поток больше не нужен, я ему close, а он мне -1». Типа, догадывайтесь сами. Пословица такая была – дурная голова ногам покоя не даёт.

Таких «несуществующих» проблем не один десяток в каждой мало-мальски крупной программе

Нет, не таких, и дело именно в этом. Тот же close при записи в файл обрабатывать надо, и даже обязательно, а при чтении – не нужно и вредно. Результат malloc обрабатывать бессмысленно во всех случаях. А вот, скажем, если не обрабатывать результат read – то программа сгодится только в /dev/null. Просто случаи эти РАЗЛИЧАТЬ надо, а для этого использовать головной мозг.

когда раскатываешь обновление сервиса на 2000+ узлов, раскиданных по всей стране

Отлично, я готов признать, что в этой ситуации systemd может быть полезен (если эксплуатирующая команда готова иметь секс с его багами). Вот пусть тогда systemd и используют только те, у кого такая ситуация имеет место – сколько таких пользователей в мире? Тысяча? Две? И пусть при этом не пытаются его навязать мне и всем остальным ни в чём не повинным пользователям линукса. Тогда, и не раньше, я соглашусь перестать катить баллон на sjw-шного гадёныша поцтеринга.

Описанные вами быстрофиксы — это явный признак плохой архитектуры и культуры разработки.

Ну ты поучи жену щи варить, ага…

Какой к дьяволу «некритический случай», если процессу не хватило памяти – он мёртв! Всё!

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

обойдётся в if после каждого malloc’а

Какой кошмар!

и в мучительные размышления «а что делать-то на двадцатом уровне вложенности вызовов» при каждом, опять же, malloc’е.

Никаких мучительных размышлений: установить код с причиной и вернуть ошибку на уровень выше.

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

Чем это принципиально отличается от достижения, например, RLIMIT_NOFILE? В обоих случаях мы упёрлись в ограничение ресурса, которое мы можем адекватно обработать.

И «программа несовместима с данным окружением» — это неправильный вывод из данной ситуации. Правильный — «нагрузка превысила установленный предел»; в таком случае давать отлуп «лишним» клиентам это очевидное решение.

Коротко говоря, обработка результата malloc не поможет ничему. Вообще. Совсем. Даже в том 0.0001% случаев. Это просто бессмысленная трата сил.

Хорошо, не обрабатывайте.

Вот пусть тогда systemd и используют только те, у кого такая ситуация имеет место – сколько таких пользователей в мире? Тысяча? Две? И пусть при этом не пытаются его навязать мне и всем остальным ни в чём не повинным пользователям линукса. Тогда, и не раньше, я соглашусь перестать катить баллон на sjw-шного гадёныша поцтеринга.

Мне глубоко наплевать на Поттеринга. systemd — это инструмент, который по взвешенной сумме качеств для меня значительно лучше предыдущего. То, что подавляющее большинство дистрибутивов перешло на него как init по умолчанию или вообще единственный, означает, что для них это тоже так. Вы же со своей стороны вольны использовать дистрибутивы, разработчики которых имеют иное мнение на этот счёт.

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

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

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

Да тебя вообще-то никто и не спрашивает, просто жизнь так устроена: не хватило памяти – «изя всё».

Какой кошмар!

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

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

Слушай, ты реально когда-нибудь на чистом Си (не на плюсах с их исключениями и тем более не на джавах с питончиками) всерьёз писал? Ты хоть раз пытался сделать ЭТО? Не в теории на лоровском форуме, а собственными пальчиками? Для каждой (буквально каждой!) функции – способ сигнализировать об ошибке, для каждого (КАЖДОГО!!!) вызова функции – обработку? Твою ж двадцать, такого даже в ядре нашего любимого линукса не делают, это физически если и возможно, то не в исполнении живого человека, для этого нужны какие-нибудь киборги или инопланетяне.

Из всего Си++, который крив как российская дорога, пожалуй, обработка исключений – самое кривое, что там есть, самая отвратительная мерзость из изобретённых в Си++ (который из этих отвратительных мерзостей состоит процентов на 90, так что там есть из чего выбирать) – и несмотря на всю мерзотность, даже я в некоторых программах исключения таки использую. Я, заметим, разборчивей подавляющего большинства тех, кто пишет на плюсах, я не использую ничего из его стандартной библиотеки (вообще ничего! даже iostream), я не использую ничего из так называемых «стандартов», в т.ч. я не пользуюсь namespace’ами и ещё много чем, но исключения всё-таки хоть изредка, но применяю – просто потому что альтернатива им, описанная абзацем выше, представляет собой реальный ад, настолько адский, что вообще-то я ни разу нигде и никогда не видел полностью выстроенной пирамиды обработки ошибок в программе, где не применяются исключения. Что и понятно, трудоёмкость кодинга при этом возрасла бы раза в три по меньшей мере, этого в реальной жизни никто себе позволить не может.

Чем это принципиально отличается от достижения, например, RLIMIT_NOFILE?

Ничем. ulimits устанавливаются, чтобы аварийный (!) процесс не смог завалить всю систему, а их значения в норме основаны на ожиданиях администратора системы, в какие рамки должна (заведомо) вписываться запускаемая программа при её нормальном функционировании. Если процесс не аварийный, но в любой из RLIMIT_* упёрся, то данная программа с данными лимитами функционировать не может, нужно или менять лимиты, или переделывать программу.

подавляющее большинство дистрибутивов перешло на него

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

Я, заметим, разборчивей подавляющего большинства тех, кто пишет на плюсах, я не использую ничего из его стандартной библиотеки (вообще ничего! даже iostream)

Свою написал?

Свою написал?

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

Единственное, что вроде бы есть в стандартной библиотеке плюсов, но написать пришлось-таки самому – это строку, ну то есть да, у меня есть свой заменитель для string, поскольку интерфейс std::string крив и дебилен, не делает ничего из того, что нужно мне, но зато засорён толпой методов, которые мне нафиг не нужны, так что std::string меня не устраивал бы, даже если бы не был std::.

пусть при этом не пытаются его навязать мне и всем остальным ни в чём не повинным

Очередная жертва, изнасилованная Поттерингом

этот массовый переход на systemd произошёл в результате приватных договорённостей менеджеров

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

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

С болезненно раздутым ЧСВ

Результат malloc обрабатывать бессмысленно во всех случаях.

И при этом, разумеется, безграмотный говнокодер.

Это настолько классическая комбинация хейтерских черт что хоть сейчас в палату мер и весов.

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

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

А теперь вспомним, что я написал:

Где-то могут быть другие настройки overcommit, где-то можете упереться в RLIMIT_AS, где-то не влезете в адресное пространство, где-то банально сработает эвристика в ядре при попытке выделить явно больше памяти, чем свободно + swap, а где-то это вообще будет не Linux.

«Во всех кроме RLIMIT_AS», ага.

Слушай, ты реально когда-нибудь на чистом Си (не на плюсах с их исключениями и тем более не на джавах с питончиками) всерьёз писал? Ты хоть раз пытался сделать ЭТО? Не в теории на лоровском форуме, а собственными пальчиками? Для каждой (буквально каждой!) функции – способ сигнализировать об ошибке, для каждого (КАЖДОГО!!!) вызова функции – обработку? Твою ж двадцать, такого даже в ядре нашего любимого линукса не делают, это физически если и возможно, то не в исполнении живого человека, для этого нужны какие-нибудь киборги или инопланетяне.

Представляете, каждый день так пишу, и моя команда так пишет, и иной код просто не пройдёт review!

(Разумеется, кроме тех очень немногочисленных случаев, когда возвращённая ошибка на самом деле не ошибка (device probing), или её действительно можно проигнорировать (ошибка close() после ошибки write()).)

Я даже больше скажу: у нас каждая функция (даже static!) и вообще каждый символ в file scope имеет хотя бы краткую Doxygen-документацию!

ulimits устанавливаются, чтобы аварийный (!) процесс не смог завалить всю систему, а их значения в норме основаны на ожиданиях администратора системы, в какие рамки должна (заведомо) вписываться запускаемая программа при её нормальном функционировании. Если процесс не аварийный, но в любой из RLIMIT_* упёрся, то данная программа с данными лимитами функционировать не может, нужно или менять лимиты, или переделывать программу.

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

массовый переход на systemd произошёл в результате приватных договорённостей менеджеров (замечу, совершенно не технарей) между собой

С вами всё ясно, можете не продолжать.

каждый день так пишу

Минуточку, на чистом Си? Мне предлагается в это поверить? Ну хоть проект-то какой?

вообще каждый символ в file scope имеет хотя бы краткую Doxygen-документацию!

Это как раз абсолютно нормальная практика, особенно при работе в команде. Мне не вполне понятен здесь восклицательный знак в конце фразы. И какое это имеет отношение к бессмысленной обработке ошибок, обработке не поддающихся – тоже непонятно. Написать функцию и не снабдить её даже коротким комментарием – это как под собственную задницу подложить лишний репейник, уже через час можно не вспомнить, что такое сам имел в виду; ну а оформить этот комментарий в doxygen’овском стиле и вовсе ничего не стоит. Чем ты меня тут удивить-то хотел?

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

Ну это да, скоро двадцать лет как (если быть точным, с 2003 года), причём это можно узнать из открытых источников, два клика, начиная с моего профиля на ЛОРе. Опять же, если быть совсем точным, с тех пор я не писал за деньги в составе команды. За деньги, но не в команде – писал, и в команде, но не за деньги – тоже, а вот так, чтоб по-серьёзному – ну да, давно не брал в руки шашек. А что, за эти двадцать лет изобрели серебряную пулю? Или программисты внезапно стали дешевле?

С вами всё ясно

Да с тобой уже тоже всё ясно, причём не только мне: systemd 251 (комментарий)

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

systemd-emacsd

Минуточку, на чистом Си? Мне предлагается в это поверить? Ну хоть проект-то какой?

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                              970          18497          18209          83159
C/C++ Header                  1085           6331          18540          20139
JSON                           401            750              0           7194
Bourne Shell                    41            650            410           2836
Assembly                        96            218            822           1420
SQL                             53              8              4            512
CSS                              3             79              7            415
XML                              2             10             14            366
HTML                             6              0              0            327
JavaScript                       2             36             74            178
INI                             12              0              0            132
YAML                             1              0              0             55
Dockerfile                       2             13              0             35
make                             1              7              0             19
SVG                              6              0              0              6
-------------------------------------------------------------------------------
SUM:                          2681          26599          38080         116793
-------------------------------------------------------------------------------

Это дерево проектов, над которыми работает наша команда.

Остальная информация под NDA, сорян.

даже я в своих говнодемонах на говнопыхе

Чем же так интересен пых в написании демонов?..

Чем же так интересен пых в написании демонов?..

Ничем. Как и любой другой ЯП.