Zend Guard Run-time support missing!
When you start Zend Guard for the first time, i.e. the Loader module ZendGuardLoader.so, chances are you run into some problems and you will see the "Zend Guard Run-time support missing" page.
The main problem for this error is that the Zend Guard loader module is not loaded/installed properly. Unfortunately the error page may be the result of not just one single problem so we have to cycle through the possibilities.
This page will help you find the problem and I will even throw in some additional information you might need if you are not so computer savvy. Note the Environment Disclaimer at the bottom for my setup details.
Initial tests
Before we dive into deeper territory you should do a few tests first to sort out things.
Proper installation result
The first question is how do you even know if Zend Guard Loader is loaded and working properly. Does the configuration even see the information and is doing something. I have a webpage to answer just this question so please see How to test if ZendGuardLoader.so is installed and working.
If you don't see anything about the Zend Guard Loader with that test you have found your first and hopefully only problem. Please check your configuration with that test before proceeding here.
Simple loading problems
Some other tests are about two simple loading problems.
First what do you get when you use the wrong version, i.e. the 32-bit instead of the 64-bit. This problem is the same on Linux and Windows system. Unfortunately the two libraries use the exact same name. Second what happens if you have the wrong path information in the config (or the file in the wrong place) or misspelled the information. Check out my document How to see ZendGuardLoader.so loading problems.
The problem and fixes are obviously easy but not how the problem raises its head. The document tells where to look and find the signs.
If all has been checked and you still have a problem it is time for this.
SELinux problems
First! If you have Windows and still a problem: This is not for you! I am very sorry but as the title implies this is specific to Linux. Unfortunately I don't have any other suggestions for Windows users beyond the previous points.
Okay, you have a Linux system and you have cleared the previous hurdles but you still see the webpage with the title Zend Guard Run-time support missing! and you have some serious doubts about using Zend Guard? I guess you are looking at some problems involving SELinux like I did.
Do you have SELinux
The first answer we need is if we even have SELinux running. This can be tested easily with the following:
| [root@centos ~]# sestatus | ||
| SELinux status: | enabled | |
| SELinuxfs mount: | /selinux | |
| Current mode: | enforcing | |
| Mode from config file: | enforcing | |
| Policy version: | 24 | |
| Policy from config file: | targeted | |
If you see this it means SELinux is installed and enabled.
Is SELinux causing a problem
The second answer we need is if SELinux is causing the problem with Zend Guard Loader. Luckily this can be easily tested as well. It is so easy that you will find this answer in many places as the solution. Which I think it is not, it's just a simple workaround. Anyhow, try this
| [root@centos ~]# echo 0 >/selinux/enforce | ||
| [root@centos ~]# service httpd restart | ||
| Stopping httpd: | [ OK ] | |
| [ OK ] | ||
| [root@centos ~]# echo 1 >/selinux/enforce | ||
This will turn off SELinux temporarily and when you restart httpd you should be fine and see your webpages correctly. If that is the case SELinux is your problem. Now, if the following should not get your problem solved you will have to check the file access in terms of SELinux, i.e. context. I will not go into details how to fix that because such an problem is not specific to this Zend Guard module.
Before we go to the solution I have a nasty little secret. If you use php -v as described in other places to see if Zend Guard Loader is loaded this will look great as you can see here
| [root@centos ~]# php -v |
| PHP 5.3.3 (cli) (built: Jan 11 2012 19:53:01) |
| Copyright (c) 1997-2010 The PHP Group |
| Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies |
It looks as if Zend Guard is loaded properly but your website will tell you it isn't. If SELinux is your problem you have to look somewhere else for clues.
Check the httpd error_log
The definitive traces and a hint if SELinux is the culprit can be found in the httpd/error_log and like I mentioned above with php there is another nasty little secret with httpd/error_log.
To see the problem you have to restart your daemon twice! For whatever reason, on my system, I cannot see the problem in the log the first time around. If you don't see it the first time you should see the follow line the second time.
| Failed loading /usr/lib64/httpd/modules/ZendGuardLoader.so: |
| /usr/lib64/httpd/modules/ZendGuardLoader.so: cannot enable executable stack as shared object requires: Permission denied |
This is a problem with the ZendGuardLoader.so file itself provided by Zend. I am not sure if they are aware of the problem or how this should be tackled and fixed from their side but following is the solution to fix this problem on your system.
Executable stack
For the solution I think we don't have to go into detail about what cannot enable executable stack as shared object requires really means but I have found this Security Enhancements[pdf] doc that explains the story behind it. It also contains the solutions which I have next.
Header Information
The problem lies in the header information of the file and SELinux makes sure these conditions are met.
If you want to check your file first and see what the problem is run the following. If you are curious you can use it without fgrep if you like, the output is only a little more than a dozen lines. If you don't have eu-readelf try readelf. It has a similar output but not everything is on one line so you have to run it without grep.
| [root@centos ~]# eu-readelf -l /usr/lib64/httpd/modules/ZendGuardLoader.so |fgrep STACK |
| GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 0x8 |
In this file an executable stack seems to be required because of the letter E in RWE at the end but in fact none is available and the flag was set unintentional. Unfortunately the linker defaults to the safe side and marks the executable as requiring a stack.
execstack
Ordinarily this means that the executable should be compiled accordingly but there is a tool that fixes just the header information for our purpose. The tool to query or set the executable stack flag is execstack and part of prelink package. You can find and install that package with yum. After that you simply run this command:
| execstack -c /usr/lib64/httpd/modules/ZendGuardLoader.so |
If you check the header information again you will see that the E is gone and only RW remains. Restart your httpd daemon and your webpage should load. You may want to restart the daemon twice to have a proper log. In my log the old error still shows up after the first restart.
Environment Disclaimer
The error and fixes is not specific to any platform because it is mostly related to PHP. The describtion above should apply to operating systems like Linux, Windows or Apple and you should only have to substitute the paths for your OS. The solutions should also work for cloud environments like Amazon's AWS EC2. Because it is PHP centric the problem is not related to a framework like Zend, WordPress, Joomla, Drupal.
My environment
Here is some information about the environment. Although my experience and instructions are specific to Linux and as just mentione a lot will apply to other systems like Windows as well especially when you use Apache or some of the WAMP packages like XAMPP.
The Initial tests above are in fact similar on Linux and Windows and the links to my documents about Zend Guard in that first section apply for all platforms.
In my case and the examples listed here are about PHP 5.3.3 with Zend Guard on Linux and CentOS 6/x86_64. As you can see this is about 64-bit but I think that the results (problems) will be similar for a 32-bit loader. All software installations on my system are done with yum so any paths I will mention my be different if you don't have the same Linux distribution and don't use yum.
