У меня есть демон (на twisted), который ожидает POST запросы и пишет кое-какую информацию в PostrgreSQL базу, при чем постгресовский модуль сигфолтит (будем считать это за данное).
Собственно, какие будут рекоммендации, как сделать демон устойчивым?
У меня есть следующие идеи:
1. Пересобрать питон с возможностью перехвата segmentation fault (привел просто как вариант).
2. Запускать демон из башевского скрипта бесконечным циклом. Т.е. сразу по завершению дочернего процесса (процесса twisted, запущенного “twistd -ny server.tac”), он будет перезапущен заново. Минус - рутовый логгер по-умолчанию пишет в stdout, т.е. в никуда.
3. Разделить логику на “seg fault safe (1)” и “seg fault non-safe (2)” и запускать (2) из (1), взаимодействовать через perspective broker или через еще что-нибудь подобное. В этом случае - полное разделени ввода-вывода, что само по себе не так уж и плохо, но во-первых - дополнительные потери скорости, во-вторых усложнение архитектуры.
А кто как-то по-другому решал такую проблему?

ZAN
Минус - рутовый логгер по-умолчанию пишет в stdout, т.е. в никуда.

И что мешает перенаправить вывод?

Ничего не мешает :)
Но вообще говоря, если демон полностью конфигурируется из config файла, то это значит, что скрипт-запускатель его тоже должен парсить. С другой стороны, можно просто забить на этот логгер и использовать только свои, или попробовать его перенастроить.
Основной вопрос все-таки - как еще можно решить проблему?

У нас тоже регулярно крашится.
Сидит демон-мастер, следит за порожденными сервисами (их больше десятка, разные задачи у каждого типа и некоторые запускаются в 2-3 экземплярах).
Если кто-то помер - нужно запустить заново. Общаются через очередь сообщений.

А можно чуть по-подробнее про очередь сообщений? Это я так понимаю, паттерн посредник, где посредник - это демон мастер?

нет. У нас это Java JMS в проприентарной реализации Sonic. Apache ActiveMQ пятой версии сильно глюкава, а четвертая - слишком слаба.
Думаю, это - не лучшее решение.
Очень привлекательно выглядит AMQP. На PyCon общался с ребятами, которые применяют у себя RabbitMQ - были очень довольны.

В любом случае использование MQ позволяет легче распарралеливать задачи и при этом вполне доступно разработчикам с оносительно невысокой культурой программирования. Хоть и ценой некоторого снижения возможного предела быстродействия (несущественный на самом деле аргумент).

Спасибо. Есть над чем поразмыслить