Erreur Interne du Serveur; activer le débogage ne fournit aucune information supplémentaire
Je travaille avec Mediawiki 1.25.1 sur CentOS 7.2 sous Apache 2.4.3. Je travaille avec Mediawiki 1.26.4 sur CentOS 7.2 sous Apache 2.4.6. Je rencontre une erreur de serveur interne après la modification et l'envoi d'une page:
Il n'y a pas d'informations supplémentaires dans /var/log/httpd/error_log. Selon Manuel: Comment déboguer , j'ai ajouté ce qui suit à LocalSettings, puis j'ai redémarré Apache:
$ Sudo tail -7 LocalSettings.php
# Added by JW for debugging (JUN 2016). Keep commented unless needed.
$wgShowExceptionDetails=true;
$wgShowSQLErrors=true;
error_reporting( -1 );
ini_set( 'display_errors', 1 );
?>
L'ajout de $wgShowExceptionDetails, error_reporting et d'amis ne fournit aucune information supplémentaire pouvant être trouvée. error_log est propre, access_log est propre. Nous avons activé error_log = php_errors.log, mais le serveur ne produit pas php_errors.log. Nous n'avons aucune idée où chercher ailleurs.
Nous avons exécuté mysqlcheck my_wiki --auto-repair --user=... --password=... et il ne signale aucune erreur. apachectl configtest renvoie immédiatement Syntax OK. Cependant, le problème persiste.
Nous avons également effectué une mise à niveau vers MediaWiki 1.26.4 (à partir de 1.25.1) dans l’espoir de corriger cette erreur de serveur interne sans joie. Il persiste toujours et je ne peux toujours pas obtenir d'informations supplémentaires à ce sujet.
QUESTIONS: Comment fait-on vraiment activer les informations de débogage? Comment pouvons-nous recueillir plus d'informations sur le problème qui sévit sur ce serveur?
(Veuillez fournir des éléments exploitables en réponse à la question; et ne fournissez pas de liens hors site nous invitant à essayer certaines choses sur une autre page qui peuvent ou ne peuvent pas fonctionner. Veuillez également fournir des réponses pour la question spécifique qui a été posée. demandé, et pas d'autres questions qui n'ont pas été posées.)
Voici le plus récent "message d'erreur inutile" de error_log après la mise à niveau vers MediaWiki 1.26. Cela vient de la fin de /var/log/httpd/error_log quand une demande a été soumise pour mettre à jour une page wiki.
...
[Fri Oct 28 21:05:04.456126 2016] [suexec:notice] [pid 1053] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri Oct 28 21:05:04.457260 2016] [:notice] [pid 1053] ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/) configured.
[Fri Oct 28 21:05:04.457283 2016] [:notice] [pid 1053] ModSecurity: APR compiled version="1.4.8"; loaded version="1.4.8"
[Fri Oct 28 21:05:04.457290 2016] [:notice] [pid 1053] ModSecurity: PCRE compiled version="8.32 "; loaded version="8.32 2012-11-30"
[Fri Oct 28 21:05:04.457295 2016] [:notice] [pid 1053] ModSecurity: LUA compiled version="Lua 5.1"
[Fri Oct 28 21:05:04.457299 2016] [:notice] [pid 1053] ModSecurity: LIBXML compiled version="2.9.1"
[Fri Oct 28 21:05:04.495066 2016] [auth_digest:notice] [pid 1053] AH01757: generating secret for digest authentication ...
[Fri Oct 28 21:05:04.632965 2016] [mpm_prefork:notice] [pid 1053] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips configured -- resuming normal operations
[Fri Oct 28 21:05:04.632994 2016] [core:notice] [pid 1053] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
Quelques personnes ont commenté les messages de démarrage. Je ne savais pas que c'était anormal puisque Apache le faisait toujours. Nous avons récemment apporté le changement suivant pour y remédier (mais cela n'a pas résolu le problème de "non information"):
# diff /etc/httpd/conf.d/mpm_prefork.conf.bu /etc/httpd/conf.d/mpm_prefork.conf
9,13c9,13
< StartServers 1
< MinSpareServers 1
< MaxSpareServers 5
< ServerLimit 10
< MaxClients 10
---
> StartServers 4
> MinSpareServers 4
> MaxSpareServers 8
> ServerLimit 32
> MaxClients 32
Aucun d'entre nous n'est un administrateur professionnel, nous ne savons donc pas si cela suffit pour résoudre le problème. Nous sommes un groupe de développeurs de logiciels libres et ouverts qui exploitent un serveur Web et un wiki pour aider les utilisateurs.
Voici le "brièveté maximale" /etc/php.ini:
# cat /etc/php.ini | egrep -v '(^;|^\[)' | sed '/^$/d'
engine = On
short_open_tag = Off
asp_tags = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = 17
disable_functions =
disable_classes =
zend.enable_gc = On
expose_php = On
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = Off
html_errors = On
variables_order = "GPCS"
request_order = "GP"
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
cli_server.color = On
date.timezone = "UTC"
pdo_mysql.cache_size = 2000
pdo_mysql.default_socket=
SMTP = localhost
smtp_port = 25
sendmail_path = /usr/sbin/sendmail -t -i
mail.add_x_header = On
sql.safe_mode = Off
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
ibase.allow_persistent = 1
ibase.max_persistent = -1
ibase.max_links = -1
ibase.timestampformat = "%Y-%m-%d %H:%M:%S"
ibase.dateformat = "%Y-%m-%d"
ibase.timeformat = "%H:%M:%S"
mysql.allow_local_infile = On
mysql.allow_persistent = On
mysql.cache_size = 2000
mysql.max_persistent = -1
mysql.max_links = -1
mysql.default_port =
mysql.default_socket =
mysql.default_Host =
mysql.default_user =
mysql.default_password =
mysql.connect_timeout = 60
mysql.trace_mode = Off
mysqli.max_persistent = -1
mysqli.allow_persistent = On
mysqli.max_links = -1
mysqli.cache_size = 2000
mysqli.default_port = 3306
mysqli.default_socket =
mysqli.default_Host =
mysqli.default_user =
mysqli.default_pw =
mysqli.reconnect = Off
mysqlnd.collect_statistics = On
mysqlnd.collect_memory_statistics = Off
pgsql.allow_persistent = On
pgsql.auto_reset_persistent = Off
pgsql.max_persistent = -1
pgsql.max_links = -1
pgsql.ignore_notice = 0
pgsql.log_notice = 0
sybct.allow_persistent = On
sybct.max_persistent = -1
sybct.max_links = -1
sybct.min_server_severity = 10
sybct.min_client_severity = 10
bcmath.scale = 0
session.save_handler = files
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440
session.bug_compat_42 = Off
session.bug_compat_warn = Off
session.referer_check =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 5
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
mssql.allow_persistent = On
mssql.max_persistent = -1
mssql.max_links = -1
mssql.min_error_severity = 10
mssql.min_message_severity = 10
mssql.compatability_mode = Off
mssql.secure_connection = Off
tidy.clean_output = Off
soap.wsdl_cache_enabled=1
soap.wsdl_cache_dir="/tmp"
soap.wsdl_cache_ttl=86400
soap.wsdl_cache_limit = 5
ldap.max_links = -1
Je pense que nous avons compris comment diagnostiquer le problème. Pendant tout ce temps, nous nous sommes concentrés sur les journaux d'erreurs car nous considérons qu'une panne de serveur 500 est une erreur et nous avons spécifié que les erreurs devaient être consignées dans le fichier error_log dans les fichiers de configuration.
En désespoir de cause, nous avons grepé l'ensemble du système de fichiers pour * "Erreur interne du serveur". Et voilà, mod_security ne respecte pas les paramètres de configuration:
# grep -IR 'Internal Server Error' /var/log
...
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
/var/log/httpd/modsec_audit.log:HTTP/1.1 500 Internal Server Error
...
/var/log/httpd/modsec_audit.log-20161024:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161024:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161024:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161024:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161024:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161024:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161024:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161024:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161024:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161016:HTTP/1.0 500 Internal Server Error
/var/log/httpd/modsec_audit.log-20161016:HTTP/1.0 500 Internal Server Error
...
<no error_log entries>
Je suis d'accord avec mod_security pour me connecter à leur propre fichier. Je suis excepté qu'ils ne se sont pas connectés à l'endroit où nous leur avons dit de passer par php.ini, et cela a perdu des mois en heures de travail et en problèmes. Tout ce qu'ils avaient à faire était d'écrire un message occasionnel dans error_log et cela aurait été réglé il y a des mois.
Ce type d'erreur est dû à une mauvaise configuration du fichier .htaccess. php n'a rien à voir avec cela. Vous devez déboguer Apache avec des commandes de diagnostic utiles
apachectl configtest
aide utile est ici https://serverfault.com/questions/232145/command-to-check-validity-of-Apache-server-config-files
PHP Parse error: syntax error, unexpected 'error_reporting'...
Il manque un point-virgule (;) à la fin de la ligne précédente, c'est-à-dire:
$wgShowExceptionDetails=true;
Une "erreur interne du serveur" (code: 500) est une erreur très générique (catch all). C'est pourquoi vous avez besoin du journal error_log du serveur pour plus d'informations. Si vous utilisez le serveur Web Apache, cela est souvent causé par des erreurs de syntaxe dans les fichiers de configuration Apache par répertoire (fichiers. .htaccess]). Des erreurs de syntaxe peuvent également se produire si les modules de serveur requis ne sont pas installés (car les directives ne peuvent pas être interprétées).
PHP déclenchera également une erreur 500 si une erreur fatale se produit et si error_reporting/display_errors est supprimé.
Vous dites que vous avez une erreur de serveur interne à 14h20, mais que cela ne figure pas dans votre extrait de journal (vous n’avez probablement pas vu la réponse 500 dans votre journal d’accès). Cela me fait penser que le processus enfant s'est écrasé - sur une version par défaut de centos, le noyau aurait dû être vidé.
Si tel est le cas, il y a un problème avec Apache ou PHP build. Le code écrit en PHP ne peut pas causer un tel crash (il ne peut que déclencher le code binaire qui se bloque ensuite). Mettre à jour MediaWiki ne vous aidera pas dans un tel scénario. Vous pouvez consulter le fichier core dans gdb, mais la première étape consiste à vérifier que PHP et Apache sont mis à jour (et en inclure les versions lorsque vous posez des questions ici).
Il est quelque peu alarmant de constater que vous atteignez maxrequestworker deux fois dans votre fichier journal. Et y at-il une raison pour exécuter -DFOREGROUND?