2 votes

/script de renaissance de /etc/inittab en cours de migration de RHEL/CentOS 5.x vers 6.x

Je dispose d'un script perl non forkant fonctionnant en tant que démon de sockets TCP (ce script est un backend pour un jeu multijoueur) dans CentOS 5.7. Il est lancé et relancé par /etc/inittab :

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

Il est redémarré chaque nuit par la tâche cron :

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

(où le fichier /tmp/pref.pid est créé par le script lui-même).

Cette configuration a bien fonctionné pour moi depuis de nombreuses lunes. Maintenant, j'essaie de passer à CentOS 6.x et j'ai créé un nouveau fichier /etc/init/pref.conf après avoir lu "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

Et je peux le démarrer avec

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

et je vois également le script fonctionner sous l'utilisateur afarber avec "ps uawx" et écouter le port 8080 (comme il se doit) avec "netstat -an".

Mais mon problème est que je ne peux pas arrêter ou redémarrer le script (et j'en ai besoin pour la tâche cron nocturne) :

# sudo initctl restart pref
initctl: Instance inconnue :

# sudo initctl stop pref
initctl: Instance inconnue :

Des idées s'il vous plaît ?

(Et je ne veux pas installer de logiciels tiers, comme daemontools/Tivoli/etc. - car je veux que mon serveur web soit facilement réinstallable et déplaçable vers d'autres hébergeurs).

MISE À JOUR : voici ce que je vois -

# 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: Instance inconnue :

# initctl restart pref
initctl: Instance inconnue :

MISE À JOUR2 :

Mon script a 2 particularités :

1) Lorsqu'il reçoit le signal SIGTERM ou SIGINT, il écrit des données dans PostgreSQL et cela prend 10 à 15 secondes

2) Lorsqu'il est démarré de nombreuses fois, alors les exécutions ultérieures échoueront immédiatement, car seule la 1ère instance pourra écouter sur le port TCP 8080

Et dans /var/log/messages je vois :

...
17:44:25 static init: processus principal pref terminé, relance
17:44:26 static init: processus principal pref (2128) terminé avec le statut 98
17:44:26 static init: processus principal pref terminé, relance
17:44:26 static init: processus principal pref (2133) terminé avec le statut 98
17:44:26 static init: relance de pref trop rapide, arrêtée

est-ce peut-être la raison et y a-t-il quelque chose que je pourrais faire ? (peut-être retarder les démarrages ultérieurs de quelque manière que ce soit ?)

3voto

Miguel Reznicek Points 21

Le problème est que après votre processus semble se terminer de lui-même. Nous n'avons pas le message de journal pour le processus avec le pid 2083 mais je soupçonne qu'il est mort de manière inattendue avant que vous n'ayez émis le prochain 'initctl restart pref' (comme l'ont fait les pids 2128 et 2133 par exemple). La clé est que 'initctl restart foo' NE FONCTIONNE QUE si le nom du job foo est toujours en cours d'exécution. S'il est mort, vous devez faire un 'initctl start foo' normal. Je suis tombé là-dessus aussi. J'appelais explicitement 'initctl stop foo' et m'attendais à ce que 'initctl restart foo' fonctionne comme avec les scripts d'initialisation. Ce n'est pas le cas. Vous devez utiliser 'initctl start foo'.

2voto

phatblat Points 2046

Que montre 'initctl list'? Avez-vous essayé 'initctl reload-configuration' après avoir créé le travail?

-2voto

Sebastian Sohr Points 51

Jeter un coup d'œil à la page de l'homme pour initctl révélera la réponse. La commande initctl ne comprend que les verbes start, stop, status pour contrôler les tâches. Il n'y a pas de verbe restart disponible.

Santé!

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X