(notice) pid enfant XXXX signal de sortie Défaillance de segmentation (11), possibilité de vidage de mémoire dans/etc/Apache2
Je continue à avoir l'erreur suivante dans mon journal Apache:
[Wed Sep 18 17:59:20 2013] [notice] Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.8 with Suhosin-Patch configured -- resuming normal operations
[Wed Sep 18 18:06:30 2013] [notice] child pid 7505 exit signal Segmentation fault (11), possible coredump in /etc/Apache2
[Wed Sep 18 18:06:35 2013] [notice] child pid 7497 exit signal Segmentation fault (11), possible coredump in /etc/Apache2
[Wed Sep 18 18:13:53 2013] [notice] child pid 7501 exit signal Segmentation fault (11), possible coredump in /etc/Apache2
[Wed Sep 18 18:13:53 2013] [notice] child pid 7506 exit signal Segmentation fault (11), possible coredump in /etc/Apache2
[Wed Sep 18 18:14:14 2013] [notice] child pid 8708 exit signal Segmentation fault (11), possible coredump in /etc/Apache2
J'ai essayé de revenir en arrière en procédant comme suit:
user:~$ Sudo gdb
user 8670 8571 0 18:12 pts/3 00:00:00 grep --color=auto httpd
user:~$ Sudo gdb
(gdb) attach 8571
Attaching to process 8571
Reading symbols from /bin/bash...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libtinfo.so.5
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/x86_64-linux-gnu/libnss_compat.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_compat.so.2
Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnsl.so.1
Reading symbols from /lib/x86_64-linux-gnu/libnss_nis.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_nis.so.2
Reading symbols from /lib/x86_64-linux-gnu/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2
0x00007f553000244e in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) backtrace
#0 0x00007f553000244e in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x0000000000441419 in ?? ()
#2 0x000000000044255c in wait_for ()
#3 0x0000000000432c88 in execute_command_internal ()
#4 0x00000000004352fe in execute_command ()
#5 0x000000000041e31d in reader_loop ()
#6 0x000000000041ca87 in main ()
(gdb) backtrace full
#0 0x00007f553000244e in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x0000000000441419 in ?? ()
No symbol table info available.
#2 0x000000000044255c in wait_for ()
No symbol table info available.
#3 0x0000000000432c88 in execute_command_internal ()
No symbol table info available.
#4 0x00000000004352fe in execute_command ()
No symbol table info available.
#5 0x000000000041e31d in reader_loop ()
No symbol table info available.
#6 0x000000000041ca87 in main ()
No symbol table info available.`
Je ne peux pas faire la tête ou l'histoire du problème.
J'ai également exécuté gdb sur Apache comme suit:
user:~$ Sudo gdb Apache2
Reading symbols from /usr/sbin/Apache2...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/sbin/Apache2
[Thread debugging using libthread_db enabled]
Using Host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Apache2: bad user name ${Apache_RUN_USER}
[Inferior 1 (process 6925) exited with code 01]
Je ne sais pas si c'est lié à ce problème, mais dès que j'ai installé gdb, le message suivant s'affiche lorsque je me connecte:
=> There were exceptions while processing one or more plugins. See
/var/log/landscape/sysinfo.log for more information.
sysinfo.log contient les éléments suivants:
for process_info in info.get_all_process_info():
File "/usr/lib/python2.7/dist-packages/landscape/lib/process.py", line 49, in get_all_process_info
process_info = self.get_process_info(process_id)
File "/usr/lib/python2.7/dist-packages/landscape/lib/process.py", line 85, in get_process_info
process_info["state"] = STATES[state]
KeyError: 't (tracing stop)'
2013-09-18 18:43:35,633 ERROR Processes plugin raised an exception.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/landscape/sysinfo/sysinfo.py", line 99, in run
result = plugin.run()
File "/usr/lib/python2.7/dist-packages/landscape/sysinfo/processes.py", line 18, in run
for process_info in info.get_all_process_info():
File "/usr/lib/python2.7/dist-packages/landscape/lib/process.py", line 49, in get_all_process_info
process_info = self.get_process_info(process_id)
File "/usr/lib/python2.7/dist-packages/landscape/lib/process.py", line 85, in get_process_info
process_info["state"] = STATES[state]
KeyError: 't (tracing stop)'
Un peu de fond.
J'utilise un site WordPress avec mon VPS. Le VPS est un serveur LAMP basé sur Ubuntu avec Perl et CURL installé. J'utilise APC pour la mise en cache, mais mes erreurs de segmentation sont survenues avant l'installation d'APC. Enfin, j'exécute mon serveur via le service Google PageSpeed. J'ai donc installé le mod_remoteip mod pour Apache 2.2 et un en-tête X-Forwarded-For est en place.
le noyau ulimit est illimité. Mon fichier phpinfo () peut être trouvé ici: http://tecne.ws/11v
Veuillez aider. Cela serait très appréciable!
J'ai eu ce problème et changé LogLevel warn à LogLevel debug dans la configuration Apache. Au redémarrage, il semblait y avoir une erreur de segmentation juste après mod_deflate.
Désactiver mod_deflate dans debian/ubuntu devrait simplement être Sudo a2dismod deflate
J'ai résolu ceci indirectement. Je mets Nginx devant Apache et je n'ai plus d'erreur de segmentation. Avoir Nginx devant Apache est une meilleure installation à mon avis. Vernis Cache peut également avoir résolu le problème.
Après avoir passé toute une journée à essayer de retrouver cette trace, aucune solution n’a fonctionné. Cependant, j’ai finalement transformé Apache en journalisation de niveau de débogage et j’ai immédiatement remarqué des centaines de notifications/avertissements lorsque mod_pagespeed de Google pour Apache tentait de réécrire des images à partir d’images Photon de Jetpack.
J'ai fait un simple a2dismod pagespeed et pas plus de fautes de segmentation.
J'ai aussi remarqué que mes sites tournaient plus vite maintenant avec mod pagespeed désactivé.
Il semble y avoir pas mal de rapports de bugs sur la vitesse de page à l'origine des erreurs de segmentation.
Pas sûr que ce soit juste mod_pagespeed ou la combinaison de mod_pagespeed, wordpress et php .... mais éteint maintenant le problème a disparu.
J'en ai fini pour le moment et je suis également en train de tout transférer vers Nginx maintenant. Traquer les erreurs sur Apache tourne toujours au cauchemar, avec Nginx, je peux détecter les erreurs en quelques secondes à une minute.
Ce problème est souvent causé par un module Apache. Comme vous pouvez le constater, les autres réponses concernent un module ou un autre. La réponse générique pourrait être essayez de désactiver le ou les derniers modules que vous avez activés .
Dans mon cas, le module à l'origine du problème est php7.3, sur Ubuntu 18.04. PHP 7.2 fonctionne, mais pas PHP 7.3.
Dans mon cas, l'erreur est apparue à chaque fois que j'accédais à mon site depuis iOS/MacOS Safari. Après le premier accès à partir de l'un de ces périphériques, Apache a continué à réduire les erreurs de segmentation à toute requête émanant de tout périphérique jusqu'au prochain redémarrage.
Le problème a disparu après la désactivation du module mod_spdy de Google.
J'avais le même problème avec Varnish> Apache> PHP-FPM sur Centos 6.
Je l'ai résolu en désactivant KeepAlive dans Apache.
Essayez de définir
max_input_time = -1
dans votre fichier php.ini.
de php.ini ...
; Maximum amount of time each script may spend parsing request data. It's a good; idea to limit this time on productions servers in order to eliminate unexpectedly ; long running scripts. ; Note: This directive is hardcoded to -1 for the CLI SAPI ; Default Value: -1 (Unlimited) ; Development Value: 60 (60 seconds) ; Production Value: 60 (60 seconds) ; http://php.net/max-input-time;