Особые соображения по использованию Python в скрипте init.d? - PullRequest
Новая
       64

Особые соображения по использованию Python в скрипте init.d?

9 голосов
/ 10 сентября 2009

Существуют ли какие-либо особые соображения относительно использования Python в 'init.d' скрипте, который запускается через init? (т.е. загрузка Ubuntu)

Из того, что я понимаю, используя поиск в Google / тестирование в Ubuntu, переменные среды, предоставляемые сценарию 'init.d', редки, поэтому использование "#!/usr/bin/env python" может не работать.

Что-нибудь еще?

Ответы [ 2 ]

4 голосов
/ 10 сентября 2009

Это только подчеркивает самую большую проблему с python в скрипте init.d - добавленную сложность.

Python не имеет спецификации, и env даже не должен указывать на cpython. Если вы обновитесь и сломаете Python, вам придется прикусить язык. И вероятность того, что python сломается, гораздо выше, чем sh (безопасная ставка для сценариев init.d). Причина в том, простая утилита: 

ecarroll@x60s:/etc/init.d$ ldd /usr/bin/python
    linux-gate.so.1 =>  (0xb7ff7000)
    libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7fc9000)
    libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7fc5000)
    libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7fc0000)
    libz.so.1 => /lib/libz.so.1 (0xb7faa000)
    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f84000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e21000)
    /lib/ld-linux.so.2 (0xb7ff8000)
ecarroll@x60s:/etc/init.d$ ldd /bin/sh
    linux-gate.so.1 =>  (0xb803f000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ec7000)
    /lib/ld-linux.so.2 (0xb8040000)

Python связывается с libpthread, libdl, libutil, libz, libm среди других вещей, которые могут быть повреждены. Python просто делает больше. 

-rwxr-xr-x 1 root root  86K 2008-11-05 01:51 /bin/dash
-rwxr-xr-x 1 root root 2.2M 2009-04-18 21:53 /usr/bin/python2.6

Вы можете прочитать больше о том, что вы конкретно говорите с переменными env здесь: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9 Основная проблема заключается в том, что значения по умолчанию для env можно установить в / etc / profile, который будет запускаться только в том случае, если скрипт запускается в оболочке, которая поддерживает его чтение.

1 голос
/ 10 сентября 2009

Я предполагаю, что работает какой-то демон, написанный на python, если нет, то это может не применяться.

Вы (вероятно) захотите сделать стандартную Unix двойную вилку и перенаправить дескрипторы файлов. Это тот, который я использую (Адаптировано из получателя кода ActiveState, URL которого ускользает от меня на данный момент). 

def daemonize(stdin, stdout, stderr, pidfile):
    if os.path.isfile(pidfile):
        p = open(pidfile, "r")
        oldpid = p.read().strip()
        p.close()
        if os.path.isdir("/proc/%s"%oldpid):
            log.err("Server already running with pid %s"%oldpid)
            sys.exit(1)
    try:
        pid = os.fork()
        if pid > 0:
            sys.exit(0)
    except OSError, e:
        log.err("Fork #1 failed: (%d) %s"%(e.errno, e.strerror))
        sys.exit(1)
    os.chdir("/")
    os.umask(0)
    os.setsid()
    try:
        pid = os.fork()
        if pid > 0:
            if os.getuid() == 0:
                pidfile = open(pidfile, "w+")
                pidfile.write(str(pid))
                pidfile.close()
            sys.exit(0)
    except OSError, e:
        log.err("Fork #2 failed: (%d) %s"%(e.errno, e.strerror))
        sys.exit(1)
    try:
        os.setgid(grp.getgrnam("nogroup").gr_gid)
    except KeyError, e:
        log.err("Failed to get GID: %s"%e)
        sys.exit(1)
    except OSError, e:
        log.err("Failed to set GID: (%s) %s"%(e.errno, e.strerror))
        sys.exit(1)
    try:
        os.setuid(pwd.getpwnam("oracle").pw_uid)
    except KeyError, e:
        log.err("Failed to get UID: %s"%e)
        sys.exit(1)
    except OSError, e:
        log.err("Failed to set UID: (%s) %s"%(e.errno, e.strerror))
        sys.exit(1)
    for f in sys.stdout, sys.stderr:
        f.flush()
    si = open(stdin, "r")
    so = open(stdout, "a+")
    se = open(stderr, "a+", 0)
    os.dup2(si.fileno(), sys.stdin.fileno())
    os.dup2(so.fileno(), sys.stdout.fileno())
    os.dup2(se.fileno(), sys.stderr.fileno())

Просто запустите это, прежде чем запускать цикл демона, и он, вероятно, будет действовать правильно.

В качестве примечания, я использую #! / Usr / bin / env python в качестве строки shebang в скрипте на Ubuntu, и он работает нормально для меня.

Возможно, вы все еще захотите перенаправить stdout / stderr в файл, даже если вы не запускаете демон для предоставления отладочной информации.

...