пусть python запускается в фоновом режиме с помощью функции внутри кода [duplicate]

Вот мой базовый демон Python «Howdy World», с которого я начинаю работать, когда я разрабатываю новое приложение-демон.

#!/usr/bin/python
import time
from daemon import runner

class App():
    def __init__(self):
        self.stdin_path = '/dev/null'
        self.stdout_path = '/dev/tty'
        self.stderr_path = '/dev/tty'
        self.pidfile_path =  '/tmp/foo.pid'
        self.pidfile_timeout = 5
    def run(self):
        while True:
            print("Howdy!  Gig'em!  Whoop!")
            time.sleep(10)

app = App()
daemon_runner = runner.DaemonRunner(app)
daemon_runner.do_action()

Обратите внимание, что вам понадобится библиотека python-daemon. Вы можете установить его на:

pip install python-daemon

Затем просто запустите его с помощью ./howdy.py start и остановите его с помощью ./howdy.py stop.

После нескольких лет и многих попыток, теперь я понимаю, что есть лучший способ, чем начать, остановить, перезапустить демон прямо с Python: вместо этого используйте инструменты ОС!

Короче говоря, вместо выполнения python myapp start и python myapp stop, я делаю это, чтобы запустить приложение:

screen -S myapp python myapp.py    
CTRL+A, D to detach

или screen -dmS myapp python myapp.py до начать и отделить его в одной команде .

Затем:

screen -r myapp

снова подключиться к этому терминалу. После этого в терминале можно использовать CTRL + C, чтобы остановить его.

Есть множество проблем, которые нужно заботиться, когда вы становитесь хорошим процессом демона :

• предотвращают дампы ядра (многие демоны выполняются как root, а core дампы могут содержать конфиденциальную информацию).
• корректно ведут себя внутри chroot gaol
• . UID, GID, рабочий каталог, umask и другие параметры процесса соответственно для использования
• relinquish повышенные привилегии suid, sgid
• закрыть все дескрипторы открытых файлов, причем исключения в зависимости от варианта использования
• ведут себя правильно, если они начинаются внутри уже снятого контекст, такой как init, inetd и т. д.
• настроить обработчики сигналов для разумного поведения демона, а также с определенными обработчиками, определенными в прецеденте
• , перенаправить стандарт потоки stdin, stdout, stderr, поскольку процесс демона больше не имеет управляющего терминала
• обрабатывает ПИД-файл как кооперативную консультативную блокировку, которая представляет собой целую банку червей в само со многими противоречивыми, но действительными способами t o behave
• позволяют надлежащую очистку, когда процесс завершается
• , фактически становятся процессом демона, не приводя к зомби

Некоторые из них являются стандартными, как описано в канонической литературе Unix ( Advanced Programming in UNIX Environment , покойным У. Ричардом Стивенсом, Addison-Wesley, 1992). Другие, такие как перенаправление потока и PID-обработка файлов , являются обычным поведением, которое ожидали бы большинство демонов, но это менее стандартизировано.

Все они покрываются PEP 3143 «Стандартная библиотека процессов демона». Реализация ссылок python-daemon работает на Python 2.7 или новее, а Python 3.2 или более поздней.

Альтернатива - создать нормальную, не-демонанизированную программу Python, а затем демонтировать ее извне с помощью supervisord . Это может сэкономить много головных болей и является * nix- и языковым переносом.

Я изменил несколько строк в примере кода Sander Marechal (упомянутый @JeffBauer в принятом ответе ), чтобы добавить метод quit(), который выполняется до того, как демон остановлен. Это иногда очень полезно.

Вот он.

Примечание: я не использую модуль «python-daemon», потому что документация по-прежнему отсутствует (см. также много других вопросов SO) и довольно неясна (как правильно запустить / остановить демона из командной строки с помощью этого модуля?)

Эта функция преобразует приложение в демона:

import sys
import os

def daemonize():
    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, 'w')
    se = open(os.devnull, 'w')
    os.dup2(si.fileno(), sys.stdin.fileno())
    os.dup2(so.fileno(), sys.stdout.fileno())
    os.dup2(se.fileno(), sys.stderr.fileno())

Вероятно, не прямой ответ на вопрос, но systemd можно использовать для запуска вашего приложения в качестве демона. Вот пример:

[Unit]
Description=Python daemon
After=syslog.target
After=network.target

[Service]
Type=simple
User=<run as user>
Group=<run as group group>
ExecStart=/usr/bin/python <python script home>/script.py

# Give the script some time to startup
TimeoutSec=300

[Install]
WantedBy=multi-user.target

Я предпочитаю этот метод, потому что большая часть работы выполняется для вас, а затем ваш сценарий демона ведет себя аналогично остальной системе.

-Orby

Еще одна вещь, о которой нужно подумать о демонализации в python:

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

Если вы этого не сделаете, обработчик все еще может считать, что файлы открыты, а ваши сообщения просто исчезнут - другими словами, убедитесь, что регистратор знает, что его файлы закрыты!

Это предполагает, что когда вы демоннизируете, вы закрываете ВСЕ дескрипторы открытых файлов неразборчиво - вместо этого вы можете попытаться закрыть все, кроме файлов журнала (но обычно проще закрыть все, а затем снова открыть те, которые вы хотите).

80% времени, когда люди говорят «демона», им нужен только сервер. Поскольку вопрос совершенно неясен в этом вопросе, трудно сказать, какова возможная область ответов. Так как сервер достаточно, начните там. Если фактический «демон» действительно необходим (это редко), прочитайте в nohup как способ демонстрации сервера.

До тех пор, пока фактический демон фактически не понадобится, просто напишите простой сервер.

Также посмотрите на реализацию WSGI reference .

Также посмотрите на Simple HTTP Server .

«Есть ли какие-то дополнительные вещи, которые нужно учитывать?» Да. Около миллиона вещей. Какой протокол? Сколько запросов? Как долго обслуживать каждый запрос? Как часто они прибудут? Будете ли вы использовать выделенный процесс? Потоки? Подпроцессы? Написание демона - большая работа.