Processus tué par SIGHUP après la lecture renvoie ERESTARTSYS

Question

Nous avons une application qui appelle un script PHP qui se connecte à une base de données Oracle pour faire certaines choses. :) Cela ne marche pas bien parfois.

Nous exécutons maintenant la partie PHP via strace depuis le début.

C'est à quoi il ressemble quand tout fonctionne bien (tout fonctionne, la connexion DB est construit, la requête exécutée, la DB est déconnectée à nouveau, etc.):

10:30:17.935486 connect(8, {sa_family=AF_INET, sin_port=htons(1521), sin_addr=inet_addr("10.1.1.55")}, 16) = -1 EINPROGRESS (Operation now in progress) 
10:30:17.935546 times(NULL)    = 2908590046 
10:30:17.935569 brk(0xda4000)   = 0xda4000 
10:30:17.935594 poll([{fd=8, events=POLLOUT}], 1, 60000) = 1 ([{fd=8, revents=POLLOUT}]) 
10:30:17.940338 getsockopt(8, SOL_SOCKET, SO_ERROR, [519270883345301504], [4]) = 0 
10:30:17.940368 fcntl(8, F_GETFL)  = 0x802 (flags O_RDWR|O_NONBLOCK) 
10:30:17.940388 fcntl(8, F_SETFL, O_RDWR) = 0 
10:30:17.940408 getsockname(8, {sa_family=AF_INET, sin_port=htons(62498), sin_addr=inet_addr("192.168.22.30")}, [16]) = 0 
10:30:17.940437 getsockopt(8, SOL_SOCKET, SO_SNDBUF, [-4193870156763480064], [4]) = 0 
10:30:17.940458 getsockopt(8, SOL_SOCKET, SO_RCVBUF, [-4193870156763409068], [4]) = 0 
10:30:17.940483 setsockopt(8, SOL_TCP, TCP_NODELAY, [1], 4) = 0 
10:30:17.940506 fcntl(8, F_SETFD, FD_CLOEXEC) = 0 
10:30:17.940652 rt_sigaction(SIGPIPE, {0x1, ~[ILL ABRT BUS FPE SEGV USR2 TERM XCPU XFSZ SYS RTMIN RT_1], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f7198b2b920}, {0x1, [PIPE], SA_RESTORER|SA_RESTART, 0x7f7198b2b920}, 8) = 0 
10:30:17.940725 write(8, "\x00\xe8\x00\x00\x01\x00\x00\x00\x01\x3b\x01\x2c\x0c\x41\x20\x00\xff\xff\x7f\x08\x00\x00\x01\x00\x00\xa2\x00\x46\x00\x00\x08\x00"..., 232) = 232 
10:30:17.940781 read(8, "\x00\x08\x00\x00\x0b\x00\x00\x00", 8208) = 8 
10:30:17.974177 write(8, "\x00\xe8\x00\x00\x01\x00\x00\x00\x01\x3b\x01\x2c\x0c\x41\x20\x00\xff\xff\x7f\x08\x00\x00\x01\x00\x00\xa2\x00\x46\x00\x00\x08\x00"..., 232) = 232 
10:30:17.974247 read(8, "\x00\x29\x00\x00\x02\x00\x00\x00\x01\x3b\x0c\x41\x00\x00\x00\x00\x01\x00\x00\x00\x00\x29\x51\x41\x00\x00\x00\x00\x00\x00\x00\x00"..., 8208) = 41 
10:30:17.976465 write(8, "\x00\x00\x00\xa4\x06\x20\x00\x00\x00\x00\xde\xad\xbe\xef\x00\x9a\x00\x00\x00\x00\x00\x04\x00\x00\x04\x00\x03\x00\x00\x00\x00\x00"..., 164) = 164 
.... 

C'est à quoi il ressemble quand tout ne fonctionne pas ok:

10:23:24.888170 connect(8, {sa_family=AF_INET, sin_port=htons(1521), sin_addr=inet_addr("10.1.1.55")}, 16) = -1 EINPROGRESS (Operation now in progress) 
10:23:24.888241 times(NULL)    = 2908548738 
10:23:24.888263 brk(0xda4000)   = 0xda4000 
10:23:24.888287 poll([{fd=8, events=POLLOUT}], 1, 60000) = 1 ([{fd=8, revents=POLLOUT}]) 
10:23:24.889769 getsockopt(8, SOL_SOCKET, SO_ERROR, [519270883345301504], [4]) = 0 
10:23:24.889807 fcntl(8, F_GETFL)  = 0x802 (flags O_RDWR|O_NONBLOCK) 
10:23:24.889827 fcntl(8, F_SETFL, O_RDWR) = 0 
10:23:24.889845 getsockname(8, {sa_family=AF_INET, sin_port=htons(62473), sin_addr=inet_addr("192.168.22.30")}, [16]) = 0 
10:23:24.889873 getsockopt(8, SOL_SOCKET, SO_SNDBUF, [-8374476973480591360], [4]) = 0 
10:23:24.889892 getsockopt(8, SOL_SOCKET, SO_RCVBUF, [-8374476973480520364], [4]) = 0 
10:23:24.889915 setsockopt(8, SOL_TCP, TCP_NODELAY, [1], 4) = 0 
10:23:24.889936 fcntl(8, F_SETFD, FD_CLOEXEC) = 0 
10:23:24.890062 rt_sigaction(SIGPIPE, {0x1, ~[ILL ABRT BUS FPE SEGV USR2 TERM XCPU XFSZ SYS RTMIN RT_1], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f2ee24b4920}, {0x1, [PIPE], SA_ 
RESTORER|SA_RESTART, 0x7f2ee24b4920}, 8) = 0 
10:23:24.890129 write(8, "\x00\xe8\x00\x00\x01\x00\x00\x00\x01\x3b\x01\x2c\x0c\x41\x20\x00\xff\xff\x7f\x08\x00\x00\x01\x00\x00\xa2\x00\x46\x00\x00\x08\x00"..., 232) = 232 
10:23:24.890186 read(8, 0xd705a6, 8208) = ? ERESTARTSYS (To be restarted) 
10:23:24.907853 --- SIGHUP (Hangup) @ 0 (0) --- 
10:23:24.908708 +++ killed by SIGHUP +++ 

Cela arrive parfois et l'application (ou au moins le script PHP et la connexion à la DB) vient se fait tuer. C'est mauvais.

• Que faites-vous des stries ci-dessus? Pouvons-nous dire qui est tué par qui?
• Pourquoi read() retournerait ERESTARTSYS? Qu'est-ce que SIGHUP (Hangup) @ 0 (0) nous dit exactement?

Answer 1

Votre processus a reçu un SIGHUP, ce qui a provoqué l'action normale de sortie.

Je ne peux pas dire qui l'a fait. Essayez une nouvelle version de strace. De ce que je peux dire, en remontant à la version 4.6 à partir de 2011, il devrait afficher plus d'informations. La version de strace que vous utilisez est d'avant 2011 et le @ 0 (0) fournit le PC du processus lorsque le signal a été reçu et l'adresse associée au signal de siginfo_t. Ni vous dira quoi que ce soit sur ce problème.

Une version plus récente fournira quelque chose comme ceci:

--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=25064, si_uid=1000} --- 
--- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} --- 

Ce premier est un autre processus d'envoi du SIGHUP. La seconde est une envoyée automatiquement à cause de certains événements. Ce dernier peut se produire lorsque le terminal de contrôle du processus se ferme ou lorsque le leader de session quitte parce que son terminal est fermé. Si vous déterminez que c'est le noyau qui envoie le signal, alors je regarde votre processus pendant qu'il s'exécute et examine les colonnes "sid" et "tty" dans la sortie ps. Cela vous indiquera le chef de session et le terminal responsable de l'envoi du SIGHUP. Peut-être que parfois votre script a un terminal de contrôle et parfois non? Le chef de session serait généralement le processus parent qui a lancé votre script, ou le parent de ce processus, ou le parent de ce processus, etc. En regardant la sortie ps et "sid" vous le dira. Si ce processus leader se termine et a un terminal de contrôle, tout ce qui est sous SIGHUP. Le moyen de résoudre ce problème serait soit que le chef ne quitte pas avant que le processus PHP ne soit terminé, soit qu'il se détache de cette session ou du terminal. Habituellement, un processus démon ou serveur ne doit pas être associé à un terminal. Voir daemon() et setsid().