Python as linux daemon

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

В какой-то момент мне потребовалось демонизировать некоторое действие на python. В сети валялась куча примеров подобной деятельности разной степени собранности. Так как в дальнейшем предполагалось использовать код демонизации в дальнейшей деятельности я решил разнести на разные части настройки и собственно демона.
В итоге файлов получилось три:

• Родительские классы — с небольшим изменением классы взятые из интернет статей
• Классы настройки — реакция на сигналы, реакция на команды и набор статических настроек для запуска
• Скрипт запуска — собирает первые два в собственно демона

Дальше я попробую описать логику работы всех трех.

Сразу скажу, что все есть на Гитхабе. Потому как если вы легко читаете питон — читать мой весьма неумелый текст может оказаться гораздо сложнее.

Собственно в первом файлике описывать толком нечего: Это почти неизменные три класса, взятые из этой статьи. Из изменений там только то, что к самому демону был прикреплен класс обработчик сигналов, и добавление сигналов в список обрабатываемых было вкручено в собственно процедуру демонизации.

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

Внутренние методы и поля могут быть какими угодно.

2)ReactFunctionCon — содержит реакцию на консольные команды. При инициализации так же получает демона. Каждый метод по названию должен соответствовать команде на которую он будет реагировать и может принимать аргументы (то, что собственно идет за командой в командной строке). Например:

3)StatCon — содержит всякие статические настройки демона. На данный момент выглядит так:

Соответственно —
Хелп строка, выводимая при неправильной передаче аргументов в какую-либо функцию (Возможно следует сделать команду хелп по умолчанию, которая выводит это сообщение?).
Метод run — собственно то, для чего все затевалось — то, что демон делает.
Адрес pid файла — для хранения процесса и все такое.
Ввод, вывод, ошибки — логгирование и прочее. По умолчанию отсылается в /dev/null

Центровой скрипт представляет интерес исключительно кодом. В общем говоря он наследует класс демона, собирает все настройки с предыдущего файла и раскладывает их по демону, и принимает команды.

Ну и собственно вопросы:
Что не так, что не очень так?
Как по вашему следует ли как-то приписывать к этому GPL, или не стоит больгеносить, и все это слишком несерьезно?
Достаточно ли адекватно я указал предыдущих авторов?

Источник

Как заставить скрипт Python работать как сервис или демон в Linux

Я написал скрипт Python, который проверяет определенный адрес электронной почты и передает новые электронные письма внешней программе. Как я могу заставить этот скрипт работать 24/7, например, превратить его в демона или службу в Linux. Нужен ли мне также цикл, который никогда не заканчивается в программе, или это можно сделать, просто выполнив код повторно несколько раз?

15 ответов

У вас есть два варианта здесь.

сделать правильный cron-задание это вызывает ваш сценарий. Cron-это общее имя для демона GNU / Linux, который периодически запускает скрипты в соответствии с установленным расписанием. Вы добавляете свой скрипт в crontab или помещаете символическую ссылку на него в специальный каталог, и демон обрабатывает задание его запуска в фоновом режиме. Ты можешь!—7—>подробнее в Википедии. Есть различные демоны cron, но ваша система GNU / Linux должна быть уже установлена.

использовать какой-то python подход (например, библиотека), чтобы ваш скрипт мог демонизировать себя. Да, это потребует простого цикла событий (где ваши события запускают таймер, возможно, обеспечивается функцией сна).

Я бы не рекомендовал вам выбирать 2., потому что вы фактически повторяете функциональность cron. Парадигма системы Linux заключается в пусть несколько простых инструментов взаимодействуют и решают ваши проблемы. Если нет дополнительных причин для создания демона (в дополнение к периодическому запуску), выберите другой подход.

кроме того, если вы используете daemonize с циклом и происходит сбой, никто не будет проверять почту после этого (как указано Невоструев Иван в комментарии этой ответ). В то время как, если скрипт добавлен как задание cron, он просто снова запустится.

Источник

Python на примере демона уведомления о новых коммитах Git

Работая в команде я люблю быть в курсе активности участников. Поэтому было решено написать демона наблюдающего за поступлением новых коммитов в репозиторий git’а. Так как я работаю в Ubuntu, то уведомление было реализовано встроенным способом — библиотекой libnotify.
Язык — Python!

В статье упоминается:
1. Демон на Python;
2. Логирование на Python;
3. Хранение конфигурационных файлов программ на Python;
4. Работа с командами ОС из скриптов Python;
5. Получения списка последних изменений из git’а;
6. Стандартные всплывающие уведомления Ubuntu.

Для реализации задачи был выбран язык Python (высокоуровневый, интерпретируемый, объектно-ориентированный и расширяемый язык программирования), так как я его не знаю.
Для начала мне очень помогли два источника:
— официальная документация: http://docs.python.org/tutorial/index.html;
— цикл статей IBM на русском языке: https://www.ibm.com/developerworks/ru/library/l-python_part_1/.

Во время изучения основ, приступаем к написанию программы.

1. Демон

В сети встречается много реализаций демонов, выбрал один из готовых с положительными отзывами и привлекательным названием: http://www.jejik.com/articles/2007/02/a_simple_unix_linux_daemon_in_python/. У этого демона были проблемы с завершением работы командой «daemon.py stop» вот в этом месте:

Это как видно возникло это из-за русской локали, фраза «No such process» в моей системе возвращалась на русском языке. Простой способ исправить — удалить эту проверку:

2. Ведение логов

Простейшим средством оповещение о процессе работы программы является использование функции print(). Но эта программа будет запускаться в качестве демона и не предполагает вывод информации о своем состоянии в консоль запуска. Удобным вариантом в этом случае является запись лога в файл. В Python’е есть встроенный способ логирования входящий в стандартную библиотеку — модуль logging (http://docs.python.org/library/logging.html).
Модуль имеет множество вариантов ведения лога (handlers, http://docs.python.org/library/logging.handlers.html): StreamHandler, FileHandler, WatchedFileHandler, RotatingFileHandler, TimedRotatingFileHandler, SocketHandler, DatagramHandler, SysLogHandler, NTEventLogHandler, SMTPHandler, MemoryHandler, HTTPHandler. Для контроля работы демона использовался FileHandler:

3. Хранение конфигурации программ на Python

Для хранения конфигурации приложений используется ini файл и встроенный модуль работы с ними ConfigParser (http://docs.python.org/library/configparser.html):

Получение значения параметров функциями (в данном случае получение integer значения):

4. Работа с командам ОС из скриптов Python

Для выполнения системных команд используется метод check_output() модуля subprocess (http://docs.python.org/library/subprocess.html):

Также можно использовать методы модуля os:

Документация рекомендует использовать subprocess.

Источник

shouro / daemon.md

A simple unix/linux daemon in Python

by Sander Marechal

I’ve written a simple Python class for creating daemons on unix/linux systems. It was pieced together for various other examples, mostly corrections to various Python Cookbook articles and a couple of examples posted to the Python mailing lists. It has support for a pidfile to keep track of the process. I hope it’s useful to someone.

Below is the Daemon class. To use it, simply subclass it and implement the run() method.

Update 2009-05-31: An anonymous contributor has written a version of the Daemon class suitable for Python 3.x. Download the Python 3.x version here. The code below is for Python 2.x

And here is an example implementation. It implements the daemon as well as it’s controlling client. Simply invoke this script with start, stop or restart as it’s first argument. Download this file.

That’s it! I hope this is of some use to someone. Happy coding!

Posted on 2007-02-02@09:09

«»»Generic linux daemon base class for python 3.x.»»»

import sys , os , time , atexit , signal

class daemon :

«»»A generic daemon class.

Usage: subclass the daemon class and override the run() method.»»»

def __init__ ( self , pidfile ): self . pidfile = pidfile

def daemonize ( self ):

«»»Deamonize class. UNIX double fork mechanism.»»»

try :

pid = os . fork ()

if pid > 0 :

# exit first parent

sys . exit ( 0 )

except OSError as err :

sys . stderr . write ( ‘fork #1 failed: <0>\n ‘ . format ( err ))

sys . exit ( 1 )

# decouple from parent environment

os . chdir ( ‘/’ )

os . setsid ()

os . umask ( 0 )

# do second fork

try :

pid = os . fork ()

if pid > 0 :

# exit from second parent

sys . exit ( 0 )

except OSError as err :

sys . stderr . write ( ‘fork #2 failed: <0>\n ‘ . format ( err ))

sys . exit ( 1 )

# redirect standard file descriptors

sys . stdout . flush ()

sys . stderr . flush ()

si = open ( os . devnull , ‘r’ )

so = open ( os . devnull , ‘a+’ )

se = open ( os . devnull , ‘a+’ )

os . dup2 ( si . fileno (), sys . stdin . fileno ())

os . dup2 ( so . fileno (), sys . stdout . fileno ())

os . dup2 ( se . fileno (), sys . stderr . fileno ())

# write pidfile

atexit . register ( self . delpid )

pid = str ( os . getpid ())

with open ( self . pidfile , ‘w+’ ) as f :

f . write ( pid + ‘ \n ‘ )

def delpid ( self ):

os . remove ( self . pidfile )

def start ( self ):

«»»Start the daemon.»»»

# Check for a pidfile to see if the daemon already runs

try :

with open ( self . pidfile , ‘r’ ) as pf :

pid = int ( pf . read (). strip ())

except IOError :

pid = None

if pid :

message = «pidfile <0>already exist. » + \

«Daemon already running? \n «

sys . stderr . write ( message . format ( self . pidfile ))

sys . exit ( 1 )

# Start the daemon

self . daemonize ()

self . run ()

def stop ( self ):

«»»Stop the daemon.»»»

# Get the pid from the pidfile

try :

with open ( self . pidfile , ‘r’ ) as pf :

pid = int ( pf . read (). strip ())

except IOError :

pid = None

if not pid :

message = «pidfile <0>does not exist. » + \

«Daemon not running? \n «

sys . stderr . write ( message . format ( self . pidfile ))

return # not an error in a restart

# Try killing the daemon process

try :

while 1 :

os . kill ( pid , signal . SIGTERM )

time . sleep ( 0.1 )

except OSError as err :

e = str ( err . args )

if e . find ( «No such process» ) > 0 :

if os . path . exists ( self . pidfile ):

os . remove ( self . pidfile )

else :

print ( str ( err . args ))

sys . exit ( 1 )

def restart ( self ):

«»»Restart the daemon.»»»

self . stop ()

self . start ()

def run ( self ):

«»»You should override this method when you subclass Daemon.

It will be called after the process has been daemonized by

start() or restart().»»»

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

How to make a Python script run like a service or daemon in Linux

I have written a Python script that checks a certain e-mail address and passes new e-mails to an external program. How can I get this script to execute 24/7, such as turning it into daemon or service in Linux. Would I also need a loop that never ends in the program, or can it be done by just having the code re executed multiple times?

15 Answers 15

You have two options here.

Make a proper cron job that calls your script. Cron is a common name for a GNU/Linux daemon that periodically launches scripts according to a schedule you set. You add your script into a crontab or place a symlink to it into a special directory and the daemon handles the job of launching it in the background. You can read more at Wikipedia. There is a variety of different cron daemons, but your GNU/Linux system should have it already installed.

Use some kind of python approach (a library, for example) for your script to be able to daemonize itself. Yes, it will require a simple event loop (where your events are timer triggering, possibly, provided by sleep function).

I wouldn’t recommend you to choose 2., because you would be, in fact, repeating cron functionality. The Linux system paradigm is to let multiple simple tools interact and solve your problems. Unless there are additional reasons why you should make a daemon (in addition to trigger periodically), choose the other approach.

Also, if you use daemonize with a loop and a crash happens, no one will check the mail after that (as pointed out by Ivan Nevostruev in comments to this answer). While if the script is added as a cron job, it will just trigger again.

Источник