> Это вообще два разных подхода решающие разные задачи. Их нельзя сравнивать.

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

> будут выгружены необходимые данные). Это уже вопрос не технический, а организационный
> -- руководство так решило.

К чему это? Думаете мне интересно что ваше руководство решило? Или вы считаете что я для этого буду вам сокет-активацию советовать? Не буду, не надейтесь. Я вполне себе недолюбливаю сокет-активацию за потенциальную возможность оверхеда или недобросовестного дерга сервиса внешними недружественными системами. Но допускаю мысль что это бывает полезно. А раз так - пусть будет сделано по человечески хотя-бы, а не очередным костылем с очередной конфигурацией где-то в 15-м по счету закоулке.

> Хотя myhand привёл пример, который так и остался не понятым. Зачем ещё
> распинаться впустую?

Он какое-то высосанное из пальца ламерство "привел". Единственное чего я понимаю - гнать таких некомпетентных админов надо из продакшна. Этот лабух даже не понимает что такое overcommit, но разводит громкие заявы про "предсказуемость". А вы как, тоже не понимаете что это такое? Ща мы увидим квалификацию всех этих НеФанатов и понимание ими базовых процессов происходящих в системах. Если что, без понимания этого заявы про предсказуемость - просто вопиющая некомпетентность: индивид настолько ламер что даже не может осознать почему непредсказуемость возникает и мнит что круто заварен^W^W его система предсказуема.

> Да, ибо уже пришёл админ и начал работать. И он чётко знает,
> что такие вещи можно делать только начиная с полвосьмого.

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

> Нет. Работа по временному расписанию добавляет предсказуемости поведения,

В каком-то роде так, но
- Состояние сложной системы в момент "полвосьмого" - не очень определенная величина и также может зависить от внешних факторов. Особенно в системе с опачами или sshd где форки процессов провоцируются внешними событиями. У вас в системах все это УЖЕ ЕСТЬ, много лет. А то что вы ретарды и заметили это только сейчас - поздравляю, блин. Что ж вы раньше в тряпочку молчали?
- Ваш юзкейс дико переклинен на серверах и мысли что все можно подогнать под расписание. Это narrow minded подход. У таких обычно еще на десктопе максималка, поэтому юзкейсов кроме серверов такие конечно же не видят.

> что даёт возможность понимать что сейчас происходит с системой
> и соотвественно как с ней сейчас нужно обращаться.

Sanity check #1: а *вы* понимаете механизм оверкоммита? Только честно. Все-равно на...ть меня у вас не получится. И понимаете влияние оного на предсказуемость? И вы его как, отключаете? Попробуйте рассказать честно, без вранья. Очень интересно посмотреть что вы можете по факту и насколько ваши слова и дела согласуются.

Sanity check #2: а вы понимаете что socket activation - лишь одна из форм overcommit-а? Как впрочем и пинок процессов по крону с разнесением по времени. В обоих случаях есть некий набор грабель.

Или вы там как, наполовину беременные? Overcommit или есть, или нет. Если уж мы про предсказуемость. Come on, дорогие НеФанаты, сейчас мы узнаем о ваших уровнях понимания системных процессов.

> Ещё раз, вы сравниваете два подхода, решающих тупо разные задачи. Не надо
> их сравнивать.

Для меня это 2 инкарнации одной и той же задачи - "запустить процесс". Их можно сравнивать и смешивать. Разумеется, учитывая worst cases и не забывая здравый смысл. То-есть дергать нечто по сокету, если репорт нужен именно полвосьмого - довольно странная идея. А я разве с этим спорил?

С точки зрения предсказуемости - я вообще за fully static memory allocation. Но это менее эффективно по ресурсам и делает жизнь програмера заметно сложнее. Поэтому применяеться только в системах с реально крутыми требованиями. Ну да, будет не круто если у авто не выпустятся подушки безопасности "потому что в системе кончилась память". Но в обычной OS требования менее лютые, и подходы под стать, что бы не лечили тут кулсисопы не понимающие азов работы своих систем.

> Там где и обычно, в /var/log. В чём проблема?

В том что большинство обломов запуска сервисов инит скриптами - туда попросту не попадает. Но разумеется я могу накодить недостающий логгинг сам. Если повезет. А так все хорошо, прекрасная маркиза. Для понимания разницы нормальной системы инициализации с гoвном и палками:

Because systemd tracks processes using the Linux kernel's cgroups instead of process identifiers (PIDs), daemons cannot "escape" systemd, not even by double-forking. 

> Кстати тут как раз была проблема в systemd, который не грузился в LXC-контейнере и
> нигде ничего не сообщал (ни на экран, ни в /var/log).

Я допускаю что там тоже могут быть неидеальности. Но там поттер по крайней мере распознал проблему и попытался хоть что-то предпринять чтобы это стало более по человечески. Как впрочем и шaттл в его апстарте. Кстати LXC всего лишь название  одного из управляторов. Вы там что, из systemd, натурально, вызываете LXCшную софтину, вместо того чтобы самим systemd и/или его тулсами? Ять, это примерно как летом в лыжах на асфальт выползать и удивляться: что за фигня - плохо едут?!

> А для лечения тупо "lxc-attach -n fail --

А, я кажется начинаю понимать. Вы вместо того чтобы юзать услуги systemd решили быть святее папы римского и поссать против ветра. Ну да, любое начинание можно сильно усложнить контрпродуктивной упертостью. А можно например, ман почитать: http://linuxmanpages.net/manpages/fedora20/man1/systemd-nspa... - и чего там сложного? Оно потом еще и запускать это по человечески умеет. И вешать читаемый лэйбл cgroup-у. Что упрощает понимание "а что это вообще такое и откуда запущено".

> вокруг этого решения в Debian.

А у поттера хватило ума на попытку запилить нормальную регистрацию VM/контейнеров. Так что этим потом еще и управлять будет реально. А смотреть какие выcepы сгородят умники типа вас я даже в проекте не желаю, ибо могу себе представить тот феерический пи...ц. Поттер делает нормальную core-функциональность, вокруг которой можно нормально потом будет всем этим пользоваться, вплоть до отдачи этого большому энтерпрайзному управлятору. А ваше гумно и палки - ну вы поняли.

> Зачем вообще за этим следить? У нас тупо recent и limit работают в iptables для таких.

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

> Хотя я вообще не понял причём тут systemd/не-systemd. Но фиг с ним...

Это я к тому что динамическое выделение ресурсов и оверкоммит были задолго до системды, так что предъявлять ему что-то за сокеты довольно криво. А где вопли на кернел, inetd, etc? C'mon babies, ща мы узнаем насколько вы понимаете что и где работает.