> Ну, я и написал выше про "прок". Жаль.Мне не требуются поучения жизни от юных ламеров, не понимающих как работают компьютеры. Это так странно? Я ни разу не видел пруфов ваших скиллов которые бы прививали мне хотя-бы минимальное уважение к вам как специалисту. Вот поттеринг может быть как человек не очень и эгоист/фигарит на своей волне. Но как специалист - достаточно убедителен. И может привести валидные аргументы. И мыслительный процесс демонстрирует. В отличие от вас.
> Тебе объяснили.
Я не увидел там логичных объяснений. Только какое-то ламерское блеяние. Неубедительно, пройдите в сад.
> Разница в том, что проблема со стартом сервиса будет наблюдаться в непредсказуемый
> заранее момент.
Ты глупый? Я уже сказал что нормальные администраторы до разворота конфигурации в продакшн тестируют как это работает, до того как пускать на автопилот. При этом нет принципиальной разницы - прописать время "сейчас + 2 минуты" или сделать конект на сокет. Предсказуемость одинаковая. А во время работы системы не так уж принципиально - наступило ли полшестого или прилетел пакет. Процесс или уж стартует или уж нет. Не вижу фундаментальных отличий в зависимости от "ситуации в системе когда наступило полшестого" или "ситуации в системе, когда прилетел пакет". А в чем принципиальное отличие, кроме критериря? Сервера вон тоже не знают когда пакеты прилетят. И роутеры. Это не мешает им работать почему-то. Хотя вы ваш ламерский спам присылаете сюда на форум явно не по крону.
Я могу себе представить что возможна глупая реализация, позволяющая пригрузить систему. Но это можно и обычному inetd предъявить, если уж на то пошло. То что по этому поводу сокет активацией лучше пользоваться в меру и с пониманием побочных эффектов - ну, ок, а с этим никто и не спорил.
> А не при плановой перезагрузке (старт системы) или
> (как для задач крона) - по известному расписанию.
Тестовый запуск сервиса запускаемого по пакету на сокет тоже можно выполнить в предсказуемый момент. А как оно там далее будет - не вижу разницы: система без присмотра админа что полшестого, что когда прилетел пакет. Да, я не собираюсь бегать каждый раз в 3 часа ночи к серверу проверить как он там пашет по крону, ты прикинь?! Что будет после этого события - не более и не менее предсказуемо чем прилет пакета в произвольный интервал: я совершенно одинаково не буду окарауливать сервер как цербер. Ни в три часа ночи, ни когда прилетел пакет.
И если уж мы о предсказуемости, нормальные запускалки позволяют полисовать ресурсы. И ресурсов или уж хватает на выполнение задач и есть блокирование от ухода вразнос, или нет. А у вас в вашей мегапредсказуемой фиговине это делать геморно и на это к тому же админы часто кладут. Так что сервисы пошедшие вразнос - кладут всю систему, вплоть до невозможности входа по ssh, на который ресурсов не осталось. Так что да, я предпочитаю предварительную аллокацию ресурсов, etc. Однако вижу валидные сценарии для сокетовой активации. А раз уж иногда надо - пусть будет сделано нормально и не валяться в еще одном закоулке, пятнадцатом по счету.
> Помимо "валидности конфигов" есть еще десяток сценариев, в которых аналогичная засада может проявится.
Ну понятно что при сильном желании прострелить пятку можно и так. Но все это можно предъвить и обычному inetd. Я не вижу - в каком месте стало хуже чем было по этому поводу. Лучше - может и станет. Например если есть возможность лимиты ресурсов по простому вписывать как параметры конфигурации вместо скриптинга жутких этажерок которые это будут подкостыливать. При том лимиты ресурсов в этом случае должны учитывать еще и работу интерпретера и скриптошита в нем. Для небольших сервисов лимит на всю эту скриптятину может превысить лимиты на всю программу. И вообще, так обрубить ресурсы "ровно по границе" не получится - больно дофига действий по пути и им это может помешать. Скажем если мы знаем что программа работает только с 2 файлами, логично разрешить только 2 дескриптора. А хаксоры будут сильно недовольны, когда на их потуги не хватит дескрипторов и все обломается по техническим причинам. Но если это делать через скриптятину - можно получить вкусных грабель. А вот запускач через сисколы может вполне неплохо порулить с минимальным влиянием на процесс. Пора бы уже признать, кидис, что первичны - сисколы. И все строится поверх них. И именно через них делается наиболее fine grained и наименее горбатое управление. Даже everything is file невозможно без сисколов - для открытия и чтения файлов нужны сисколы, однако.
> Ну вот в Debian - как раз такая и была, без всяких systemd.
Что-то я не заметил чтобы этот кусок шита писал что либо в логи при сбое запуска сервисов. Наверное потому что детектировать участь сервиса должна скприптопортянка. На что клали все с прибором.
> Если человек "при нормальных практиках" не понимает что он будет делать ошибки
> - вон из профессии.
Вот вас таких и выпрут в результате. Я только за. Вы уже иррелевантны под редхаты/центосы. Nice shot, RedHat. А скоро и с дебианобразными так будет. Будете с вашими окаменелыми останками админить локалхост - ну и славненько. А закончится все это тем что кулсисопов с неэффективными практиками вышибут и заменят на средства группового администрировния. Плюс несколько нормальных спецов для руления этими средствами. И все. А вы будете админить локалхосты, потому что ваши джедайские скиллы в скриптинге только вам и интересны, по большому счету. А в продакшне все это не только нафиг не упало но зачастую еще и все портит.
> Я не вижу как можно распространить "эти соображения" чтобы выключить оверкоммит.
Элементарно, ватсон:
- Если у тебя выключен оверкоммит, программа получит отлуп при попытке выделения памяти, если в системе памяти не хватило. А если памяти хватило - тогда будет работать. Ну и память уже никто не отберет. На самом деле все чуть хитрее, но суть какая-то такая. То-есть или получило память и успешно работает, или соотв. вызов отлупляет ошибку и программа по крайней мере в курсе что дело дрянь.
- А если у тебя оверкоммит - программе ядро может сказать что зашибись, память есть. Программа продолжит работу. Но память фактически выделяться не будет и ничем физически не обеспечена. Это дутые виртуальные адреса. Ну примерно как рубли - не подперты золотом в эквиваленте 1 к 1. И если где-то в районе полшестого может так получится что программа сунется в энный массив, захочет туда нечто записать, и стало быть, уже надо выделить эту память не декларативно, а по факту, в какой-то реальной физике, а в физике вдруг рррраз и нет свободного места - ОБАНА, ПРИПЛЫЛИ! В этот момент программе уже нельзя технически-корректно сообщить что ее запрос памяти на самом деле обломался, поскольку дутые виртуальные адреса - еще не место в физически чем-то обеспеченной памяти. Все что можно придумать - бабахнуть программе SIGSEGV. Она конечно может это обработать, но это уже заведомо фатальное происшествие, после этого уже невозможно корректное возобновление работы программы.
> Чудило, ты способен предсказать *когда* у тебя кончится память?
Все намного интереснее. Если интересует идеальная предсказуемость - память надо выделять заранее. Кроме всего прочего, overcommit это начинание сильно нагибает и если у тебя включен overcommit, о предсказуемости речь как таковая вообще не идет. Потому что система раздает виртуальные адреса, совершенно не обязательно что обеспеченные реальной памятью которая может хранить данные. И если попытаться это поюзать - можно случайно получить SIGSEGV в репу, если так вышло что система попыталась выкроить память, а ее физически уже нет, потому что overcommit - это декларация больше памяти чем есть. В надежде на то что программы по факту используют меньше памяти чем запрашивают. Что позволяет провернуть оптимизацию - выделять память не сразу а лишь когда программа по факту начинает пытаться ей пользоваться. Это экономнее по ресурсам, так в системе с одинаковой RAM в среднем можно запустить больше программ. Но про предсказуемость и технически корректную реакцию на ошибки такого рода ты можешь забыть.
Поэтому если мне нужна абсолютная предсказуемость - логично выделить память заранее, удостоверившись что она физически обеспечена. При этом out of memory в системе как таковой программе не страшен (особенно если oom killer сказали что это расстреливать только после всех). Хотя наиболее предсказуемые системы, где это убер-критично, используют "fully static memory allocation". То-есть, динамическое выделение памяти вообще не используется. И если уж программа стартанула - она никогда не свалится по out of memory. Нет выделения памяти - нет и такого понятия как "кончилась память". Да, так можно только на сях и ассемблере. Питоны и прочие шелскрипты так не умеют. Поэтому навалом убер-критичных систем пишется на урезанном субсете си. Это не только безопаснее многих иных альтернатив, но и намного предсказуемее.
И вот это литл ламо, не знающее таких основ - что-то лечит мне про предсказуемость. Хе-хе-хе, эти скриптокиды такие наивные.
>> Чтоб ты знал, sshd на каждый пук сам процесс форкнуть не дypaк,
> Не больше чем нужно.
Когда приходит пачка ботов - ему довольно много нужно. Плюс он еще и тяжелую криптографию ворочает. Дурную, RSA-based. На быстрый 25519 вместо тормозного RSA перешли далеко не все боты, а пристрелить RSA в sshd побоялись из соображений совместимости, так что нерадивый выводок ботов может изрядно жрать проц, если спецмер не принимать :P. Так что в целом там тоже с предсказуемостью все очень так себе. Видал прецеденты когда на серьезно факапнутом сервере не хватало ресурсов чтобы ssh мог child форкнуть. При этом конект к ssh удавался, но вот залогиниться невозможно. Былинный отказ. Такое никак особо и не лечится, кроме ребута сервака через side channel. Своими средствами управляемость потеряна. Бывает и так.
> И что, systemd магически решает эту проблему?
Это гораздо более глубокий факап, который чинить надо на самом деле не там. Это к тому что ты несколько переоцениваешь и предсказуемость и (не)потребление ресурсов в самых типовых операциях, которые смеешь приводить в пример. Фигли толку с твоей экономии на старте parent-процесса ssh по сокету, если он потом все-равно и будет ресурсы лопать за счет форков и даже при случае лоханется с запуском child - так что НЕЛЬЗЯ БУДЕТ ЗАЛОГИНИТЬСЯ. Потому что работает sshd так. Мне это, btw, не нравится.
> Те, кто держат шелл-хостинг и имеют проблемы с брутфорсом - будут использовать ровно то, что и прежде.
Для этого не надо иметь шелл хостинг. Для этого достаточно вывесить ssh в интернет. Если ему не навесить костылей типа порткнока - будет вот так.
> Я что-то пропустил и в systemd уже прикрутили AI, способное грамотно разделить ресурсы сервера?
Ну не AI а cgroups, допустим. Когда запускалка в курсе того что это за фигня - рулить ресурсами как-то зело проще получается. Так что опуская всякие визги НеФанатов, я в сухом остатке считаю такие фичи за жирный плюс.
> Можно сравнить удобство лимитирования ресурсов с systemd или без - но это отдельная тема. На вкус и цвет...
Cgroups are win, b*tches. Это намного лучше того что было. Хотя и не идеал.
