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

а что есть чатик по убунте? пардон

где-то есть наверняка

То ли воркер, то ли что-то из перлового
И потом апачек работает на половину, как попадёшь... Спорадический 502

Рестарт=always там уже стоит, но что-то не срабатывает. Наверное, systems считает что с самой службой все ок. Ключевых слов на погуглить не подскажете?

ну помер worker и чего? появится новый

Там это проявляется как спорадический 502, то на html, то на css всякие
если что-то и сдохло, само по себе оно восстанавливаться не собирается

странно как-то. 502 у тебя появляется, когда некуда запрос кинуть

сдох worker - у тебя master process запустил новый

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

ну кроме как логи грепать на предмет OOM, но это такоэ

опиши ситуацию подробней, есть тут под рукой всякие mod_perl - вроде не падают по oom

может, стоит посмотреть на код?

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

есть такоэ BestPractical Request Tracker, писанное на перле, работающее в данном случае с apache mod_perl
Из-за некоторых условий (лупы в зависимостях тикетов, кривое расширение по учёту времени) там начинает адски и стремительно течь память. Корневую проблему сейчас судя по всему не пофиксить, так что будем бороться с последствиями. Я уже попросил systemd грохать при OOM в первую очередь не базуданных, а httpd
В принципе, по его логике так и происходит
Но вот несколько половинчато, теперь бы ещё разобраться как httpd рестартовать, когда у них опять такое случается

Вообще там можно резвиться дальше, высаживая RT на nginx/fcgi, мож в контейнер там его, но это на перспективку.

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

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

но не лимиты в системде

"Добавить памяти" - ну дурной совет в данном случае. Как я сказал, оно утекает стремительно и совершенно безлимитно. Оно сожрёт любую память, которую дать.

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

например, powerdns + poweradmin, и базаданных бэкендом
погуглите, сейчас кучки докерфайлов для всего этого бывают