Hive Troubleshooting

From Wiki

Jump to: navigation, search

There is no software, that is problem free, so we prepared this section for your, which will show you some general steps on troubleshooting problems. Here you will also find the most common issues 1H Hive clients met and easy way to fix them.

When troubleshooting a problem it is good to be familiar with the software. So, we recommend you to check out the below articles, so that you get deeper in 1H Hive specifics and the way it works:


General Troubleshooting Guidelines

Website Does not Load

The Hive Software includes modified version of Apache's SuExec as well as modified version of the default Apache mod_cgi. In rare cases this might cause an issue with certain website. Even if the issue is not in anyway related to the Hive software you would still want to go through the same troubleshooting steps.

Identifying the Issue

In cases when there is an issue with certain website it is always important to first check the Apache error log:


You can search for errors associated with the specific user account using the following command:

grep <username> /usr/local/apache/logs/error_log

Where <username> is the actual account username.

In most cases the error message will be descriptive enough and it will guide to the exact issue and thus make it really easy to resolve.

It is possible to see "Premature end of script headers" error. Those are errors of type:

[Www Mon DD HH:mm:ss YYYY] [error] [client <IP Address>] Premature end of script headers: /home/username/public_html/<path to file>

Those include standard Date/Time format, IP address for which the error was displayed and the file that was accessed. For example:

[Thu Nov 18 05:31:50 2010] [error] [client] Premature end of script headers: /home/username/public_html/dir/file.php

Those types of errors might be just a bit trickier to troubleshoot as you will need to check the SuExec log for more information about the particular script execution. The SuExec log is:


What you need to do is match the "Premature end of script headers" error with the particular script execution. The easiest way to do so with a single command would be matching the exact time when the error occurred plus matching the results by username. You can do so by executing the following command:

grep "YYYY-MM-DD HH:mm:ss" /usr/local/apache/logs/suexec_log| grep "<username>"

Where the YYYY-MM-DD HH:mm:ss is the corresponding Date/Time format and <username> is the actual username. If we use the example above the command will look like this:

grep "2010-11-18 05:31:50" /usr/local/apache/logs/suexec_log| grep "username"

This will return result of type:

[2010-11-18 05:31:50]: info: [usr/grp]: username/username cmd: /home/username/public_html/dir/file.php php: /usr/local/php52/bin/php
[2010-11-18 05:31:50]: error: directory is writable by others: (/home/username/public_html/dir)

We can now clearly see the actual error message directory is writable by others and we know how to resolve the problem - simply assure that the directory is not world writable. Setting permissions for the directory to 755 will be sufficient.

Apache and SuExec Logs Format

We have mentioned the Apache error log and the SuExect log files above. Both files have specific format and they are regularly used. That is why we will take some time to explain the log files format.

Apache Error Log Explained

Below we will describe how to read an entry you might encounter when examining the Apache error log file (/usr/local/apache/logs/error_log). Lets use again the example from the Identifying the Issue section:

[Thu Nov 18 05:31:50 2010] [error] [client] Premature end of script headers: /home/username/public_html/dir/file.php

What this line includes is:

Most commonly the error message from the Apache error log will lead you directly to the problem resolution. If the error is with a script execution but it is not descriptive enough (as is the case with "Premature end of script headers"), you can check the SuExec Log for more details.

SuExec Log Explained

Generally you will see two types of records in the SuExec Log (/usr/local/apache/logs/suexec_log). A pair with script that is being executed and statistics for the script execution itself or a pair with script that is being executed and an error message as the execution failed.

Lets review the failed execution pair first. Here is an example:

[2010-11-18 05:36:40]: info: [usr/grp]: username/username cmd: /home/username/public_html/dir/file.php php: /usr/local/php52/bin/php
[2010-11-18 05:36:40]: error: directory is writable by others: (/home/username/public_html/dir)

The first line includes:

The second line includes:

Rectifying the Issue

As mentioned above the actual error message will most commonly lead you straight to the problem resolution. The important thing here is to know how and where to identify the actual error. Considering you are familiar with the way error messages and scrip executions are logged you should not experience any troubles whatsoever rectifying an issue.

Hive Limits Configuration and Stats Generation Log Files


All limitations for Hive are defined in the following file:


How to make modifications in the configuration file for Hive and apply custom limitations you can check in the Hive Configuration section. There you will also find instructions about the correct format for properly setting up limits for custom users and the server as a whole.

Hive - CPU Stats Log File

The automated snapshots generation for Hive are logged in the Hive log file for the server:


In case the statistics are not properly generated and there is an issue, the error will be also logged in the cpustats.log file.

Generally you should see lines of type:

Mon dd HH:mm:ss Generating our hourly snapshots!
Mon dd HH:mm:ss Snapshots success!

Where Mod dd HH:mm:ss is standard date/time format, for example:

Jan 20 21:50:45

If there is an issue with the snapshot generation for a certain hour, you will see a descriptive error message, again including a time stamp.

If you believe there is an issue with the CPU statistics generation or incorrect information is displayed, it is always good to check the cpustats.log and verify that the snapshots were properly generated.

CPU Stats - Web Interface Login Recovery

The Hive interface for a server is accessible over the web via:

The username for the login is always admin. The password can be withdrawn if you are logged in as root on the server using this command:

grep access_pass /usr/local/1h/etc/web.conf

You will get:


You can follow these instructions each time you need to acquire the password for CPU statistics access on the server. Also if you want to reset the password you should make the changes to the web.conf file.

to-user tool usage


The purpose of this tool is to make troubleshooting issues from users view point easier. This tool allows you to chroot to the user's chroot jail with a single command only.

What this tools does is:

1. chroot to /var/suexec/username
2. setuid to the UID of the username
3. setgid to the GID of the username
4. clear all other GIDs that you currently have
5. run /bin/bash

This way you can execute commands within the customers chroot and debug the issues on the command line.


to-user <username>

Once you execute the command you are logged to the users chrooted SSH environment.

NB: This tool does not make the nececery mounts. You should execute at least one php script before running this tool

Common problems and how to troubleshoot them

Cannot allocate memory

If the limitations for Hive are set too low and a certain process is using more than the allowed resources you will get a "Cannot allocate memory" error message. Here is an example error you can get when trying to execute a specific CMS modules update cron job:

/usr/local/bin/php: error while loading shared libraries: failed to map segment from shared object: Cannot allocate memory

All you need to do in such cases is increase the maximum allowed memory in the Hive limitations. This can generally be easily done via the Hive local interface -> Settings -> Hive Configuration -> Hive Limits tab -> Memory Limit as shown below:

Hive memory limits.png

Hive limitations can also be altered manually via command line and also you can adjust limits for a specific user only and choose values different from the default ones. Detailed instructions how to manually adjust Hive limits you can find in the Hive limitations article.

Character encoding issues

With some PHP setups it is required to add the following line to the php.ini in order to have proper UTF-8 support.

mbstring.internal_encoding = UTF-8

Client website related

Hive CPU statistics and interfaces related

ionCube PHP Loader issues

Each one of the 6 PHP versions Hive provides comes with ionCube preinstalled.

However, if a custom php.ini file is placed in a user's directory, it will override the global php.ini settings and Zend extensions such as ionCube will appear as missing. This can be easily fixed by adding the exact path to the ionCube extension in the php.ini file. For example, for PHP 5.2, the line you should add to the custom php.ini file is:


Note that custom php.ini files work on a per-folder basis, which means that you need to add this line to every custom php.ini file where you need this setting to apply.

How to Get Support

In case none of the articles above covers your case or they are not helpful enough, please feel free to contact us any time the day or night and leave your feedback.

In order to do so, please log in to your 1H Client Area and go to the Support section. Without hesitation file your problem and our technical support representatives will call back immediately.


In our FAQ we are logging the most common questions raised by our clients. Please feel free to check our FAQ Section any time you have a specific question. It might have already been answered :)

Personal tools