Well, we have tried it all. Updating httpd.conf, php.ini so the max execution time is 480 and restarting apache. Still get the 500 error on the upgrade. Not sure what to do at this point.
Alec, Does it make sense to do a full upgrade? If so, the readme/upgrade notes are not clear enough for me. Is there a more detailed FAQ? Thank you.
Hi @radjr,
Did you check the logs before and after attempting the upgrade? That should help narrow down any possible error messages that were recorded during the upgrade. A 500 error should always result in a log entry.
If you’re not doing a full upgrade now, what process are you following?
Regards,
Alec Smecher
Public Knowledge Project Team
I am running the patch upgrade. Here are the log files around the time I was trying to run the upgrade. Thanks.
[Sun Feb 05 03:42:55 2017] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sun Feb 05 03:42:55 2017] [notice] Apache/2.2.15 (Unix) DAV/2 mod_fcgid/2.3.6 mod_python/3.3.1 Python/2.6.6 mod_ssl/2.2.15 OpenSSL/1.0.1e-fips mod_perl/2.0.4 Perl/v5.10.1 configured – resuming normal operations
[Mon Feb 06 17:03:37 2017] [warn] mod_fcgid: process 1953 graceful kill fail, sending SIGKILL
[Mon Feb 06 19:43:14 2017] [warn] mod_fcgid: process 3937 graceful kill fail, sending SIGKILL
[Mon Feb 06 19:46:22 2017] [warn] mod_fcgid: process 3948 graceful kill fail, sending SIGKILL
[Mon Feb 06 20:03:43 2017] [warn] mod_fcgid: process 5132 graceful kill fail, sending SIGKILL
[Mon Feb 06 20:09:30 2017] [warn] mod_fcgid: process 5159 graceful kill fail, sending SIGKILL
[Mon Feb 06 20:18:04 2017] [warn] mod_fcgid: process 5211 graceful kill fail, sending SIGKILL
[Mon Feb 06 20:35:24 2017] [warn] mod_fcgid: process 5454 graceful kill fail, sending SIGKILL
[Mon Feb 06 20:52:59 2017] [notice] caught SIGTERM, shutting down
[Mon Feb 06 20:53:00 2017] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Feb 06 20:53:00 2017] [warn] RSA server certificate CommonName (CN) `Parallels Panel’ does NOT match server name!?
[Mon Feb 06 20:53:00 2017] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Mon Feb 06 20:53:01 2017] [notice] Digest: generating secret for digest authentication …
[Mon Feb 06 20:53:01 2017] [notice] Digest: done
[Mon Feb 06 20:53:01 2017] [error] python_init: Python version mismatch, expected ‘2.6.5’, found ‘2.6.6’.
[Mon Feb 06 20:53:01 2017] [error] python_init: Python executable found ‘/usr/bin/python’.
[Mon Feb 06 20:53:01 2017] [error] python_init: Python path being used ‘/usr/lib64/python26.zip:/usr/lib64/python2.6/:/usr/lib64/python2.6/plat-linux2:/usr/lib64/python2.6/lib-tk:/usr/lib64/python2.6/lib-old:/usr/lib64/python2.6/lib-dynload’.
[Mon Feb 06 20:53:01 2017] [notice] mod_python: Creating 4 session mutexes based on 50 max processes and 0 max threads.
[Mon Feb 06 20:53:01 2017] [notice] mod_python: using mutex_directory /tmp
Hi @radjr,
That looks like your Apache error log, which may be a different file from your PHP error log; can you look for the latter? (Only your host will know exactly where this will be – if you’re having trouble finding it, you may want to ask them or check their knowledge base.)
Regards,
Alec Smecher
Public Knowledge Project Team
Seems that this is a server specific thing.
log_errors boolean
Tells whether script error messages should be logged to the server’s error log or error_log. This option is thus server-specific.
BUT This is required to get any php errors to the error files. And it is ambiguous. So I am going to make the change and see what happens. But it should turned off as it is a security risk.
display_errors string
This determines whether errors should be printed to the screen as part of the output or if they should be hidden from the user.
Value “stderr” sends the errors to stderr instead of stdout. The value is available as of PHP 5.2.4. In earlier versions, this directive was of type boolean.
Note:
This is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet).
Note:
Although display_errors may be set at runtime (with ini_set()), it won’t have any effect if the script has fatal errors. This is because the desired runtime action does not get executed.
AND note that PHP errors are comingled in the apache log file when PHP runs under apache.
Here is the only error message that came out when I ran the upgrade.
/usr/lib64/python2.6/site-packages/mod_python/importer.py:32: DeprecationWarning: the md5 module is deprecated; use hashlib instead
import md5
/usr/lib64/python2.6/site-packages/mod_python/importer.py:32: DeprecationWarning: the md5 module is deprecated; use hashlib instead
import md5
[Tue Feb 07 15:12:35 2017] [warn] mod_fcgid: process 26300 graceful kill fail, sending SIGKILL
OK so here is the final answer. The mod_FCGID process is set for a 45 second time out and needs to be expanded to 300 or something longer. See this link for details: http://serverfault.com/questions/598038/internal-server-error-and-process-graceful-kill-fail
And here is the text with the solution.
I found an answer on my question, the following error is also presented in the apache error log file:
mod_fcgid: read data timeout in 45 seconds Premature end of script headers: index.php
This comes from the fast cgi configuration, I increased the IOTimeout value in /etc/httpd/conf.d/fcgid.conf
FcgidIOTimeout 45 to FcgidIOTimeout 300
Hi @radjr,
Great, glad to hear you got it going. This is the kind of server-specific detail that’s pretty tricky to debug remotely – that’s a bit of an uncommon timeout situation.
Regards,
Alec Smecher
Public Knowledge Project Team