Легко настраиваемый python daemon

[DmZ]

— PEP-8?
— нет, не слышали...

Даже в пределах одного файла пересекаются несколько стилей именования переменных и методов — очень не удобно читать. Хоть бы стиль причесали раз код вместе соединили.

[Mart_Slaaf]

Начал приводить в чувство. Действительно нехорошо получилось. Но это буду исправлять. =)

[haaji]

Статья, которую вы привели — очень клевая, она мне в свое время помогла понять, как это делается.
А вот то, как вы обернули все это в какой-то странный класс с Help-ом и Errorer-ом — это вообще не круто.

[Mart_Slaaf]

А почему не круто?
Идея плохая или реализация? А если идея — то чем плохая?

[DmZ]

И идея, и реализация :) Идея — потому что один класс из статьи это уже вполне самодостаточный и универсальный код, который будет полезен всем. Написание велосипедов сверх этого кода — это уже требование каждого отдельного проекта. Поэтому полезность скрипта уменьшается только для проектов подобного плана. Да, не спорю, если у Вас регулярно возникают подобные задачи — то переиспользование кода это путь в светлое будущее :)

По реализации. Как написали выше — ну вообще не круто. Зачем мне бегать по трем файлам и искать где настраиваются сигналы, например? А они реально размазаны по всем трем файлам. То что сигналы относятся к демону Вы поняли и сделали соотв. метод в правильном месте, но реализация заполнения массива хендлеров — оторви и выбрось. Вместо всей этой вакханалии с кучей классов, сделайте декоратор, который будет обрабатывать хендлеры и подготавливать все необходимое для последующей настройки. Например:

from daemon import Daemon, signal
from signal import SIGTERM

class MyDaemon(Daemon):

  def run(self):
    pass

  @signal(SIGTERM)
  @staticmethod
  def handler1(signum, frame):
    pass

Да, Вам придется подумать как правильно и красиво это написать, но читабельность и переиспользуемость повысится на порядок — все будет в одном месте, будет видно что и как управляет демоном.

Про reacts4daemon можно написать практически тоже самое — почему что-то внешнее должно решать как ведет себя мой демон. Добавьте метод типа do_action() к демону — пусть он сам парсит что может делать, а что нет. Если кто-то захочет — то переопределит этот метод в своем HisDaemon. Получим минус несколько классов и плюс к читаемости и пониманию.

Статическая конфигурация? Зачем Вам писать столько строк кода, если Вы их все равно дублируете — внесите настройки в сам класс MyDaemon. Тогда у Вас останется один подключаемый файл (daemon.py с основным классом и декоратором) и один основной файл, который несет в себе конфигурацию. Взглянув на последний будут видны и настройки, и порядок выполенения кода/сигналов. И под себя нужно будет менять один основной файл, а не несколько как сейчас :)

[DmZ]

По-хорошему оба Ваших файла «настроек» можно объединить в один, что-то типа такого:

import sys
from signal import SIGTERM
from daemon import RichDaemon, signal

class MyDaemon(RichDaemon):

  usage = """ 
              Usage: .....
               start - Start daemon
               ...
          """
  pidfile = "/var/run/daemon.pid"
  stderr = "/dev/null"

  def run(self):
    pass

  @signal(SIGTERM)
  def handler1(self, signum, frame):
    pass

if "__main__" == __name__:
  my_daemon = MyDaemon()
  my_daemon.do_action(*sys.argv[1:])

Что будет гораздо проще воспринимать :)

[Mart_Slaaf]

Спасибо огромное, за развернутые ответы =)
В моем случае — это весьма повторяемая задача. И, вроде, как раз пытался сделать максимальную вынесенность в отдельный файл всех настроек.
Я, честно говоря, не нашел настроек сигналов вне настроечного класса. По поводу декоратора — в любом случае очень классный вариант, я сейчас буду активно думать. По поводу всего остального занимаюсь осмыслением сказанного Вами. Мне кажется, что такой вариант чуть дольше для каждоразового переписывания под нового демона.
Еще раз спасибо, я очень и очень буду думать =)

[PaulOkopny]

Несколько лет назад использовал изначальный скрипт в собственном проекте, правда, пришлось его допиливать немного (дописывал метод status, например)… даже думал выложить свою версию. А потом понял, что это всё в общем-то бессмысленно, когда есть upstart и куча аналогичных продуктов.

[ilil]

А почему бы не воспользоваться уже готовыми решениями:

• supervisord (Python)
• BluePill (Ruby)

или даже circus?

[mocksoul]

А чем python-daemon не угодил?