История изменений

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

«УМВР» расшифровывается как «у меня всё работает». В данном случае работало не у меня, а у по меньшей мере 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% случаев? Нет, вот ты всерьёз это всё?

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

«УМВР» расшифровывается как «у меня всё работает». В данном случае работало не у меня, а у по меньшей мере 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% случаев? Нет, вот ты всерьёз это всё?