Wywołanie demona w skrypcie /etc/init.d jest blokowane, nie działa w tle


9

Mam skrypt Perla, który chcę demonizować. Zasadniczo ten skrypt perla będzie czytał katalog co 30 sekund, czytał znalezione pliki, a następnie przetwarzał dane. Dla uproszczenia rozważmy następujący skrypt Perla (o nazwie synpipe_server, w nim znajduje się dowiązanie symboliczne /usr/sbin/):

#!/usr/bin/perl
use strict;
use warnings;

my $continue = 1;
$SIG{'TERM'}  = sub { $continue = 0; print "Caught TERM signal\n"; };
$SIG{'INT'} = sub { $continue = 0; print "Caught INT signal\n"; };

my $i = 0;
while ($continue) {
     #do stuff
     print "Hello, I am running " . ++$i . "\n";
     sleep 3;
}

Więc ten skrypt zasadniczo drukuje coś co 3 sekundy.

Następnie, gdy chcę demonizować ten skrypt, umieściłem również ten skrypt bash (zwany także synpipe_server) w /etc/init.d/:

#!/bin/bash
# synpipe_server : This starts and stops synpipe_server
#
# chkconfig: 12345 12 88
# description: Monitors all production pipelines
# processname: synpipe_server
# pidfile: /var/run/synpipe_server.pid
# Source function library.
. /etc/rc.d/init.d/functions

pname="synpipe_server"
exe="/usr/sbin/synpipe_server"
pidfile="/var/run/${pname}.pid"
lockfile="/var/lock/subsys/${pname}"

[ -x $exe ] || exit 0

RETVAL=0

start() {
    echo -n "Starting $pname : "
    daemon ${exe}
    RETVAL=$?
    PID=$!
    echo
    [ $RETVAL -eq 0 ] && touch ${lockfile}
    echo $PID > ${pidfile}
}

stop() {
    echo -n "Shutting down $pname : "
    killproc ${exe}
    RETVAL=$?
    echo
    if [ $RETVAL -eq 0 ]; then
        rm -f ${lockfile}
        rm -f ${pidfile}
    fi
}

restart() {
    echo -n "Restarting $pname : "
    stop
    sleep 2
    start
}

case "$1" in
    start)
        start
    ;;
    stop)
        stop
    ;;
    status)
        status ${pname}
    ;;
    restart)
        restart
    ;;
    *)
        echo "Usage: $0 {start|stop|status|restart}"
    ;; esac

exit 0

Tak więc (jeśli dobrze zrozumiałem dokument dla demona) skrypt Perla powinien działać w tle, a dane wyjściowe powinny zostać przekierowane, /dev/nulljeśli wykonam:

service synpipe_server start

Ale oto, co otrzymuję zamiast tego:

[root@master init.d]# service synpipe_server start
Starting synpipe_server : Hello, I am running 1
Hello, I am running 2
Hello, I am running 3
Hello, I am running 4
Caught INT signal
                                                           [  OK  ]
[root@master init.d]# 

Więc uruchamia skrypt Perla, ale uruchamia go bez odłączania go od bieżącej sesji terminala, i widzę, że dane wyjściowe są drukowane w mojej konsoli ... co nie jest tym, czego się spodziewałem. Co więcej, plik PID jest pusty (lub tylko z linią, żaden pid nie jest zwracany przez demona ).

Czy ktoś ma pojęcie o tym, co robię źle?

EDYCJA: może powinienem powiedzieć, że korzystam z komputera Red Hat.

Scientific Linux SL release 5.4 (Boron)

Czy wykonałby to zadanie, gdyby zamiast używania funkcji demona użyłem czegoś takiego:

nohup ${exe} >/dev/null 2>&1 &

w skrypcie init?

Odpowiedzi:


4

Sugeruję demonizowanie skryptu perl bezpośrednio zamiast dodawania dodatkowej warstwy daemonfunkcji skryptu inicjującego redhat . Trudno jest uzyskać właściwe demony, jeśli spróbujesz je napisać samodzielnie. Proc :: Daemon jest dość prosty.

Oto dyskusja na temat pisania demonów perla .

Dodatkowa odpowiedź: użyj daemontools i Proc :: Daemontools . Zapewnia to kompleksowy system zarządzania demonem i prawdopodobnie już masz już zainstalowane demony. Niektórzy ludzie nie lubią Daemontools, ale wykonuje to zadanie.

Bez względu na to, ile razy piszę demona, wciąż wydaje się to dziwne. Może powinienem po prostu użyć dæmon.


2

Jeśli używasz Debiana i jego pochodnych, użyj start-stop-daemonopcji -b, aby rozpocząć proces bez problemu.


To jest maszyna RedHat, więc powinieneś użyć daemoni killproczamiast tego
MariuszS

1
To rozwiązało mój problem dzisiaj. W Ubuntu skopiowałem /etc/init.d/skeleton i nie mogłem zrozumieć, dlaczego nie działa w tle. Zakładałem, że zostało już ustawione jako tło, ale okazuje się, że tak nie jest.
Ryan,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.