Segmentation Fault in Apache with WordPress

1 Views

This is not a question… rather an answer.

Problem

Read More

Browser is returning: “ERR_EMPTY_RESPONSE”, “no data received”, “the connection was reset”, etc…

Apache error log is returning: “Segmentation fault” 

sudo tail -f /var/log/apache2/error.log

[notice] child pid 10857 exit signal Segmentation fault (11)
[notice] child pid 10703 exit signal Segmentation fault (11)

Before running around the interwebs looking for answers in a forest of confusion and Godaddy bashing, check to see if the Suhosin Extension is installed by placing the phpinfo() function somewhere in one of your PHP scrips. 

phpinfo(); die();

If you find that the Suhosin Extension is installed, you can remove it quite easily: 

sudo apt-get remove php5-suhosin

Restart Apache: 

sudo service apache2 restart

At this point, you should be good to go. Hope this helps at lest one person. I know I spent a good chunk of time hunting this down.

Cheers!

Post Views: 1

Related posts

Leave a Reply

2 comments

  1. I just fixed my connection reset problem by changing the theme. It seems an old and unsupported theme was causing the problem. After spending hours trying to figure out what was wrong with my server..and finding nothing in the logs :-

    Somehow, WordPress should be able to handle this in a more intuitive way…

  2. I have spent over a year investigating a nearly identical issue. My Apache2 system hosts four virtual hosts. Two of them run WordPress. Occasionally, the server would return status 520 for the WordPress virtual hosts only (the non WordPress content would still serve) and the error log would fill with set faults. Restarting apache resolved the issue. Web searches turned up results like this thread, recommending extensions or plugins to disable, but none of them addressed my issue.

    Finally, it occurred to me to write a simple shell script to restart apache when it fails to serve the WordPress content. A web searched turned up dozens of discussions in which frustrated apache sys admins had resorted to the same solution. Apparently, this is the fix, ugly as it is.

    Here’s the script I ended up using, in case it helps someone else.

    #!/usr/bin/sh
/usr/bin/curl -f -s -A "apachecheck" -o /dev/null --head $1
if [ $? -ne 0 ] ; then
    /usr/bin/systemctl restart apache2
fi