After switching several servers over from APF to CSF, my colleagues and I noticed that there are times during the day that LFD just chews away CPU, even while the process claims it’s “sleeping”:

root 15785 35.6 0.1 194496 93104 ? Ss 00:00 474:54 lfd – sleeping

35.6% CPU? What is it possibly doing?

In one of their FAQs, one of the developers from ConfigServers recommended disabling the following features in the csf.conf file, one by one to help narrow it down:

LF_DIRWATCH = “0″
CT_LIMIT = “0″
LF_HTACCESS = “0″
LF_MODSEC = “0″
LF_DIRWATCH_FILE = “0″
PT_LIMIT = “0″

Now, we already had these disabled – our use of LFD is limited to the downloading of global allow/deny lists only, as we don’t wish to use CSF for login failure detection at this time.  So it was a bit puzzling at why, even with the main functionality of LFD disabled, it was using so much CPU.

An strace against LFD’s PID gave us the answer – it showed that LFD was continually parsing the various log files on the server, seemingly in a never-ending loop.  This appeared to correlate with the “LD_PARSE” value of 5 seconds.  When your servers are as large and busy as ours, your log files tend to be huge – and there’s no way that CSF is parsing those logs in 5 seconds or less.

To resolve this, we set the LF_PARSE value a bit higher to allow it to rest a bit. Since we aren’t using LFD for login failure tracking, we essentially do not have a need for it to frequently scan the server’s logs. We haven’t had a problem with LFD since.

If you go into WHM > List Accounts and all your accounts are showing an unlimited quota and 0 disk space usage, you probably have a quota problem.

First thing, try running

/scripts/fixquotas

This’ll take a while depending on your current disk usage, but will usually fix the problem. If it doesn’t, make sure that quotas are on for your filesystem.  Look at /etc/fstab, and in the fourth column (the options column), make sure that ‘usrquota’ is specified for the file system that contains your user home folders.  For example, this is how ours looks:

LABEL=/     /           ext3    defaults,noatime,usrquota 0  0
LABEL=/home    /home          ext3    defaults,noatime,usrquota 0  0

If /home is part of the / partition, then the quotas need to be applied to / .

Now, remount the partitions with new options.  For the root ( / ) partition for example, you’d run the following command:

mount -o remount /

Then run the following command to update quotas:

/scripts/initquotas

If the problem indicates a problem writing to /aquota.user or similar, make sure the file isn’t set to immutable:

chattr -ia /aquota.user

After following these steps, if you’re still having a problem feel free to submit a support ticket and we’ll help you out!

After upgrading to cPanel 11.28, a number of our users indicated that databases were missing from their cPanels, despite the actual databases existing on the server.  There are a number of things that can cause this, including corrupted Perl modules and MySQL not running, but the major cause that I’ve seen is from the new database mapping functionality.  As you may know, cPanel has vastly improved their migration capabilities by recently changing how databases are mapped to user accounts, now allowing database names without user prefixes.  However, this seems to cause an issue when databases exist on the server with invalid names.

Check your /var/lib/mysql folder and see if you maybe have folders in there named incorrectly. On one of my servers, the admin renamed several of the databases to $dbname.bak when making changes, and when the database quota script ran it was erroring out. After you move or remove these folders, run the following commands:

/scripts/update_db_cache

/usr/local/cpanel/bin/setupdbmap

Assuming you’ve removed all the invalid databases from the MySQL folder, you should now be able to see the ones that were previously missing.

500 Internal Server Errors are one of the most common PHP issues that I see customer experience, and it will occur mostly on servers with suPHP or PHP running as CGI.  These errors can be caused by something on the server, or an issue on the user’s site. Here ‘s what you should do if you see errors:

Check the logs

You can solve most problems quickly just by looking at the logs:

/usr/local/apache/logs/error_log

/usr/local/apache/logs/suphp.log

Here are some common errors:

SoftException in Application.cpp:357: UID of script "/home/user/public_html/test.php" is smaller than min_uid

SoftException in Application.cpp:422: Mismatch between target UID (511) and UID (510) of file "/home/user/public_html/test.php"

SoftException in Application.cpp:264: File "/home/user/public_html/test.php" is writeable by others

These are all permission/ownership issues, indicating that the owner of the PHP file being called in incorrect, or the permissions are higher than what is allowed in suphp.conf.

Invalid directions in .htaccess

If you’re running PHP in CGI or suPHP mode, you can’t use php_flag or php_value directives in .htaccess – you either need to use htscanner to allow Apache to parse those commands, or make php-related changes in php.ini within the user’s account. You can check the Apache error log in /usr/local/apache/logs/error_log to see if you get something like this:

/home/user/public_html/.htaccess: Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration

If the error log indicates a problem with .htaccess, you need to remove the directives indicated and make sure your ssyntax is correct, and that they are in the correct places.

Incorrect ownership or permissions

PHP scripts and their immediate parent folder will usually have permissions limits when PHP runs in CGI/suPHP mode. By default, PHP files and their parent folders can not have group or ‘other’ writable permissions, and cannot be owned by a user on the system other than than the user that owns the home folder it is located in. Additionally, cPanel’s implementation of suPHP does not allow PHP to execute via browser from locations that are not inside a user’s home folder. The first thing you should check is that the PHP script and its parent folder(s) are not writable by ‘group’ or ‘other’, or owned by a different system user. You can usually see if this is an issue by tailing the suphp log in /usr/local/apache/logs/suphp.log, or whatever the suphp.conf has set as the log location.

You can adjust suPHP’s permissions allowances in /opt/suphp/etc/suphp.conf to allow ‘group’ and ‘other’ writable permissions if it’s necessary by modifying these values:

allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

If the problem is with the min_uid value being too low (such as if you’re running a PHP script as root), you can also modify the “min_uid” and “min_gid” values to be more permissive. Changing anything in the suphp.conf requires a restart of Apache.

SuPHP binary missing its “sticky” permissions

Take a look at the suphp binary. It should look a bit like this, and in most shells, will be highlighted in red:

-rwsr-xr-x 1 root root 341K Mar 30 12:25 /opt/suphp/sbin/suphp*

If it’s missing the ‘s’ in the permissions column, you need to re-add the sticky bit to allow users on the system to execute it properly:

chmod +s /opt/suphp/sbin/suphp

Last resort

If all else fails, you could be running a bum Apache build.  Try running EasyApache to reinstall to see if that fixes the problem.  You can also submit a support request to us and we may be able to fix this for you: