Zoom Search Engine FAQ - Troubleshooting CGI

Q. I have uploaded my files but get an error "no search query entered", or "error reading ..." or "Forbidden you don't have permission ..."

  • Check that you have uploaded all files required (listed at the end of indexing).
  • Check that you have uploaded these files in binary mode with your FTP client (NOT ascii or text mode)
  • Check that you have public read permissions on all files uploaded (all the .zdat files, as well as the search_template.html)
  • Check that you have specified execute permission ("chmod 755" via FTP) on the CGI file (search.cgi)
  • Check that you have uploaded your search files to a location on the server that has permission to run CGI files. Many hosting companies only allow CGI programs to run from within the "cgi-bin" directory on the server.

Q. I get a "404 Page not found" message when running the CGI.

First, check the above list of common CGI issues.

Make sure you have the correct file path for accessing the CGI you uploaded. Check if you have any virtual or redirected paths, or server side folder aliases set up. This may be misleading as to where the actual contents of the folder is located in FTP.

If you are using an IIS 6.0 server, check the FAQ further below regarding configuring IIS for CGI. IIS 6.0 returns a "404" error when CGI is not properly configured.

If your web server is running Slackware, check that it is running at least Slackware 7.0 or later. Earlier versions of Slackware has a required library as a installation option rather than as a core part of the system. If you are using a more recent version of Slackware and you still can not get it to work, then contact us via the email address on the Support page.

Q. I get a "500 Internal Server Error" message when running the CGI.

First, check the above list of common CGI issues.

Next, check that you have selected the correct build for your server's operating system. There is a Target OS selection window after you click on "CGI" in the Indexer. Note that you must re-index your site and re-upload the files after changing this option before it will take effect.

If this does not solve your problem, then check the following questions regarding "Premature end of script" error and "Unrecognized character" error.

Q. I get a "Premature end of script headers" error
Q. I get an error similar to "Unrecognized character \x90 ... "
Q. I get a "The specified CGI application misbehaved by not returning a complete set of HTTP headers" error

For IIS users

Your web server may be configured to handle all CGI files as Perl scripts. The Zoom CGI search application however is NOT a Perl script, but a binary executable, so it will fail to run in this web server configuration.

You can work-around this issue by renaming the "search.cgi" file to be "search.exe". Also consult our support page dedicated to setting up CGI for Windows IIS.

If the above does not help, your problem may be due to a bug in IIS 5.0 and IIS 6.0 related to running on a fast multi-processor computer. For more information and a hotfix from Microsoft, see this knowledge base article on Microsoft's website.

For Apache users

There are a number of different situations which may result in this error message, and they are all related to the way your Apache server is configured.

First, your Apache server may be using suEXEC, which is a feature that handles the execution of CGI and scripts and allows them to run under your own user ID (with a number of security restrictions). If this is the case, you should first check the user account/group that has ownership of the CGI file. See if this matches the suEXEC configuration for what it can execute. Second, make sure that the "search.cgi" file does not have write permissions enabled for anyone besides yourself. ie: make sure you do NOT have "search.cgi" set to a "chmod 777" setting. Likewise with the "cgi-bin" folder, or any of the .zdat files. You should only need to specify "chmod 755" for "search.cgi" (and the "cgi-bin" folder), and "chmod 644" for the .zdat files.

Even the log folder must not have public write permission. The log folder should only be permitted for owner write (eg: "chmod 744"). This will be enough for the logging to work under the suEXEC security model, because all CGIs will be running under your own user ID.

If the above does not solve your problem, then you should check if your server is configured to handle all CGI files as Perl scripts. The Zoom CGI search application is NOT a Perl script, but a binary executable, so it will fail to run in this web server configuration. You will need to change your server configuration via the "httpd.conf" file. If your "cgi-bin" folder do not contain any other Perl scripts, then you can change the settings to use "cgi-script" or "cgi-handler", instead of "perl-handler". However, if your "cgi-bin" folder does contain Perl scripts, then it may be best to create a separate directory for non-Perl CGI, and add it to your "httpd.conf" file. Specify handlers for it the same way as your existing cgi-bin directory, but use "cgi-script" instead of "perl-handler".

Another possibility for this error message is if the Apache RLimitCPU and RLimitMEM directives are set too low and the CGI is being killed off by the server, whilst in the middle of execution.

If you can not make the server configuration changes above, you should contact your web host regarding the execution of binary CGI files.

If your web host will not allow you to run binary CGI files, you can use one of the scripted alternatives such as PHP and ASP. Both of these are functionally identical except for being slower on very large sites (while CGI offers a more enterprise solution). You can see a comparison of their performance on our benchmarks page. If you are unsure what PHP, ASP or CGI are, you can also find more information here.

Q. The search stats report tool is failing to load my CGI log file

Note that Apache does not allow text files to be served via HTTP from the cgi-bin directory (it treats all files as scripts). As a quick test, try to open the file from the HTTP address via your web browser - and see if it returns an error. If so, this would be why Zoom was unable to retrieve the file.

What you should do is either:

  • Download the file via FTP, and open the local copy of the file from the search stats reports window.
  • Change your search log path to somewhere outside of the cgi-bin directory. eg. instead of "./logs/searchwords.log", something like "../logs/searchwords.log", so that it will be accessible from a URL like "http://www.mysite.com/logs/searchwords.log" and NOT "http://www.mysite.com/cgi-bin/logs/searchwords.log"

Note the need for the appropriate folder permissions if you intend to store your log files in a different directory.

Q. Search.cgi returns "bad ELF interpreter: No such file or directory" error

While trying to debug search.cgi by running the Linux version from the Linux command line. You might get this error

bash: ./search.cgi: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

This can occur if you are running the 32bit search.cgi on a 64bit version of Linux without the 32bit Linux libraries installed.

Installing the 32bit libraries can resolve this error. For example on Ubuntu run this command.

sudo apt-get install ia32-libs

On Centos run this command.

yum install glibc.i686

Different command may be required depending on your Linux distribution.

Return to the Zoom Search Engine Support page