/ etc / inittab respawn script migrando do RHEL / CentOS 5.x para 6.x

2

Eu tenho um script perl não-bifurcador rodando como um daemon de soquetes TCP (este script é um back-end para um jogo multiplayer) no CentOS 5.7. Ele está sendo iniciado e respawned por / etc / inittab:

pref:3:respawn:/bin/su -c '/usr/local/pref/pref.pl >/tmp/pref-'date +%a'.txt 2>&1' afarber

Ele está sendo reiniciado todas as noites pelo cronjob:

33    1     *     *     *     kill 'cat /tmp/pref.pid'

(onde o arquivo /tmp/pref.pid é criado pelo próprio script).

Esta configuração funcionou bem para mim desde muitas luas. Agora estou tentando atualizar para o CentOS 6.xe criei um novo arquivo /etc/init/pref.conf depois de ler "man 5 init":

start on stopped rc RUNLEVEL=3
stop on starting rc RUNLEVEL=[!3]
console output
respawn
chdir /tmp
exec /bin/su -c '/usr/local/pref/pref.pl >/tmp/pref-'date +%a'.txt 2>&1' afarber

E pode começar com

# sudo initctl start pref
pref start/running, process 2590

e também ver o script rodando sob o usuário afarber com "ps uawx" e escutando na porta 8080 (como deveria) com "netstat -an".

Mas meu problema é que não consigo parar ou reiniciar o script (e preciso disso para o cronjob noturno):

# sudo initctl restart pref
initctl: Unknown instance:

# sudo initctl stop pref
initctl: Unknown instance:

Alguma idéia, por favor?

(E eu não quero instalar qualquer software de terceiros, como daemontools / Tivoli / etc. - porque eu quero ser o meu servidor web para ser facilmente reinstalável e móvel para outros hosters).

UPDATE: aqui está o que eu vejo -

# initctl reload-configuration

# initctl list
rc stop/waiting
tty (/dev/tty3) start/running, process 1515
tty (/dev/tty2) start/running, process 1513
tty (/dev/tty1) start/running, process 1511
tty (/dev/tty6) start/running, process 1521
tty (/dev/tty5) start/running, process 1519
tty (/dev/tty4) start/running, process 1517
plymouth-shutdown stop/waiting
control-alt-delete stop/waiting
kexec-disable stop/waiting
quit-plymouth stop/waiting
rcS stop/waiting
prefdm stop/waiting
pref start/running, process 1507
init-system-dbus stop/waiting
splash-manager stop/waiting
start-ttys stop/waiting
rcS-sulogin stop/waiting
serial stop/waiting

# initctl status pref
pref start/running, process 1507

# initctl restart pref
pref start/running, process 2083

# initctl restart pref
initctl: Unknown instance:

# initctl restart pref
initctl: Unknown instance:

UPDATE2:

Meu script tem duas peculiaridades:

1) Quando obtém SIGTERM ou SIGINT, ele grava alguns dados no PostgreSQL e isso leva de 10 a 15 segundos

2) Quando é iniciado várias vezes, as execuções subseqüentes falharão imediatamente, porque somente a primeira instância poderá escutar na porta TCP 8080

E em / var / log / messages eu vejo:

...
17:44:25 static init: pref main process ended, respawning
17:44:26 static init: pref main process (2128) terminated with status 98
17:44:26 static init: pref main process ended, respawning
17:44:26 static init: pref main process (2133) terminated with status 98
17:44:26 static init: pref respawning too fast, stopped

é tudo isso, talvez o motivo e há algo que eu poderia fazer? (talvez de alguma forma atrasar os spawns subseqüentes?)

    
por Alexander Farber 05.10.2011 / 16:46

3 respostas

2

O que a 'lista initctl' mostra? Você já tentou 'initctl reload-configuration' depois de criar o trabalho?

    
por 05.10.2011 / 17:31
3

O problema é que depois que seu processo parece estar terminando sozinho. Nós não temos a mensagem de log para o processo com pid 2083, mas eu suspeito que ele morreu inesperadamente antes de você emitiu o próximo 'initctl restart pref' (como como pids 2128 e 2133 morreram por exemplo). A chave é que 'initctl restart foo' SÓ FUNCIONA se o nome da tarefa foo ainda estiver em execução. Se estiver morto, você precisa fazer um 'initctl start foo' normal. Eu corri para isso também. Eu estava explicitamente chamando 'initctl stop foo' e então esperando 'initctl restart foo' para funcionar como nos init scripts. Eles não. Você tem que usar 'initctl start foo'.

    
por 19.11.2012 / 19:35
-2

Espreitar a página man do initctl irá revelar a resposta. O comando initctl entende apenas os verbos de início, parada e status para o controle de jobs. Não há verbo de reinicialização disponível.

Felicidades!

    
por 05.10.2011 / 18:20