Memory drain issues on MySQL 5.6 ?

With the recent upgrade of WHM/cPanel, the users get the ability to upgrade their MySQL server to 5.6.x ( x > 6 ).

However, when this upgrade is done, lot of server owners are seeing memory drainage issues. An idle MySQL server tends to consume around 50% of your RAM, which is a very serious concern.  I had to upgrade a personal server of mine and faced serious issues with memory drainage. A more dig on this issue, highlighted a change brought around in the latest versions of MySQL with the parameter ‘performance_schema‘.

Starting from MySQL 5.6.6, this parameter performance_schema is enabled by default and it consumes the server memory even at an idle state. Performance Schema automatically sizes the values of several of its parameters at server start-up if they are not set explicitly, which causes the memory usage to spike up.

The workaround for this issue is to disable performance_schema. This can be done by adding the following value to the configuration file – my.cnf

performance_schema = 0

Add this line and restart MySQL server. Things should be fine from now 🙂

Note : When you try to upgrade MySQL to 5.6.x, from a VPS with 1GB of RAM provisioned you will need to edit the config file and pass the keyword to disable performance_schema ( Yes, before the upgrade ). If not, there are chances for your upgrade to fail partly, due to MySQL upgrade script installing MySQL server components each and it gets killed due to over-usage of RAM as performance_schema is enabled by default.


cPanel error – Not able to change the shell for a user ?

When trying to change the shell access for a user from WHM, do you face the following issue ?

Screenshot from 2014-07-15 11:50:26


– Even when trying to change the setting via back-end, you might face the issue :

# chsh -s /bin/bash x
Changing shell for x
setpwnam: File exists
Shell *NOT* changed.  Try again later.

– The above error indicate that there is a lock on the file  /etc/passwd Deleting /etc/ptmp will fix this issue.

# rm /etc/ptmp


cPanel – Your RPM database appears unstable !

There is a common issue with cPanel when trying to force an update.

You might get an error message which looks like :

“fatal: Your RPM database appears unstable. It is not possible at the moment to install a simple RPM”

– RPM database gets corrupted over a while,  hence preventing cP from updating.

– Give in the following, to fix this issue :

# mkdir /root/old_rpm_dbs/
# mv /var/lib/rpm/__db* /root/old_rpm_dbs/
# rpm --rebuilddb ( rebuilds the RPM database )
# /scripts/upcp  ( cPanel update )

Issue with exim – Permission denied seen in logs ?

Trouble sending mails from a cPanel – server and you end up checking  /var/log/exim_mainlog and able to spot something like  this ?

Date H=( [xx.xx.xx.xx]:xxxxxF= temporarily rejected RCPT : require_files: error for /home/ Permission denied

This happens when the  permission or ownership has been altered for the given mailbox.

Fix this issue by :

/scripts/mailperm 'account-name'

FTP error – cPanel !

– When trying to FTP, do you face this error ?

Status: Resolving address of
Status: Connecting to xx.xx.xx.xx:21…

Status: Connection established, waiting for welcome message… Response: 421 Too many connections (x) from this IP(x)

-As the logs indicate, the limit for connections from the IP you are trying to login has reached its maximum value.

– Increase this from the configuration file, the value ‘MaxClientsPerIP‘     ( pure-ftp ) or ‘MaxClientsPerHost‘ ( pro-ftpd )  and restart the service.

Alternatively, you can also terminate the existing connections from the IP, if they are not in use.

# netstat -plan | grep :21 | grep 'IP'
# kill -9 PID ( <- kill the corresponding process )

SymLinks Attacks and prevention !

The vulnerability with Symlinks and Apache is a known cause of attack.

Initially, the attacker will find a compromised ‘single’ website or domain which has got any vulnerable scripts or 3rd party applications or any themes used in it and try to get access to the files.

Once he get access to a single domain, he moves forward by creating the symlinks to other websites or even he can symlink to / (root).

For eg, if you have the following symlink set in any domain,

link -> /root , using the directory ‘link’ anyone can actually access /root and can access any sensitive file.

Rather than manually creating this sort of symlinks, the hacker can even use any perl/cgi script to create a symlink to other users of the server.

As a basic solution for this, you can ensure that Apache is configured in a way so as not to following symlinks (Options -FollowSymLinks)

— To disable the ability for Apache to allow users to follow symbolic links in their requests, remove the FollowSymLinks directive on your Directory commands.

For example, if the below was the configuration then,

<Directory "/usr/local/apache/htdocs">
Options Indexes FollowSymLinks
AllowOverrride None
Order allow,deny
Allow from all

Remove the FollowSymLinks reference so that this reads:

<Directory "/usr/local/apache/htdocs">
Options Indexes
AllowOverrride None
Order allow,deny
Allow from all

If you really need symlinks, you can use the“SymLinksIfOwnerMatch” option to only allow links from within the same user.

To prevent PHP from accessing any file outside of their directory, you need to specify the ‘open_basedir’ setting ( in PHP configuration file ) to only have access to their directory.

This option can be enabled from WHM. You might face the following error :

This security tweak uses Apache DSO style directives. If PHP is configured to run as a CGI, SuPHP or FastCGI process, the open_basedir setting must be manually specified in the relevant php.ini file. See the EasyApache documentation for more information.

– If the PHP handler is set as CGI or SuPHP, then tweak settings seen in WHM cannot be used to set the openbase_dir option.

– You need to manually specify the openbase_dir option in the global
PHP configuration file ( use php -i |grep php.ini to find the php.ini location )

Keep in mind, the root cause for this attack or vulnerability is due any unsecured scripts/plugins/applications which might be employed in any of the domains. So, keep you server free from it, in the first place 😀

cPanel – Chkservd : Exim failure messages !

– You might be getting alerts from chkservd claiming that your
IMAP/exim is getting failed and is being restarted automatically
by chkservd.

Although you might not be experiencing any real time
issue with mail delivery or logging in, something would be wrong
and as a result, you are getting this alert.

– Check /var/log/chkservd.log and see if something similar to the
following is present :

> AUTH PLAIN xxxxxxxxxxxxxxxxxxxxxx

<< 421 Service not available - closing connection
exim: ** [421 Service not available - closing connection != 2]

– This indicates that the check daemon is not able to authenticate
with the temporal exim-auth-key and therefore negative result is obtained which is forcing chkservd to restart the services in a hope
for fixing it.

– To fix this, regenerate the keys

# cd /var/cpanel/serviceauth/
# rm -rf exim
# service cpanel restart
# service exim restart

This should correct the issue.

Issue with clamd after the latest cPanel update ( 11.44.x )

After the recent update of cPanel to 11.44.x, most of the users are able to see that clamd is getting hung and consuming the server resources excessively.

On checking the processes running, we can see that clamav-cpanel plugin is consuming a lot of resources scanning the file /etc/password and spawning them without terminating.


Part of # top -c will show the following :


7761 root 25 0 35872 1704 1312 R 27.3 0.2 11:47.14 /usr/local/cpanel/3rdparty/bin/clamdscan --quiet --no-summary /etc/passwd

9714 root 25 0 35872 1708 1312 R 25.4 0.2 0:09.75 /usr/local/cpanel/3rdparty/bin/clamdscan –quiet –no-summary /etc/passwd

5982 root 25 0 35872 1704 1312 R 23.4 0.2 22:39.74 /usr/local/cpanel/3rdparty/bin/clamdscan –quiet –no-summary /etc/passwd



Even if you kill the service, the issue reproduces after a while. As of now, cPanel is yet to release a fix for this bug. 

As a temporary fix, you can try the following :


# Remove the clamAV plugin from WHM ( Home »cPanel »Manage Plugins ) – Uninstall it

# Update cPanel from backend ( # /scripts/upcp --force )

# Re-install the plugin ( Home »cPanel »Manage Plugins ) – Install it


This seems to have cleared the issue for the ones which faced this bug. Give it a try !

How can I secure my mail service – cPanel

Mail servers are exploited a lot these days to flood out spam mails from the ones which have been compromised.

Securing your mail service is very much important. There are some tweaks which can be carried out from WHM panel.

–> In Home >> Server Configuration >> Tweak Settings

Prevent “nobody” from sending mail – This will ensure that PHP
scripts running under the ownership ‘nobody’ will not be able to send mails. Most of the times, any of the vulnerable PHP script will be the culprit for sending out spams from your account.

Restrict outgoing SMTP to root, exim, and mailman – This prevents users from bypassing your mail server to send mail. Only the ones mentioned here are authorized to connect to remote SMTP servers.

// If you get an error while trying to enable SMTP restrictions, then you probably are missing an iptables module required for the proper functioning. Ask your provider to enable it for you, or if you have the ways to do it, give-in the following :

modprobe ipt_owner


–> In Home >> Service Configuration >> Service Manager,  you can find the option Antirelayd. Keep this disabled, so that each time POP3 connects authentication would be required.

–> If you are facing any issues related to IMAP getting restarted numerous times,  check

# grep 'LOGIN FAILED' /var/log/maillog|awk '{print $9}'|sort|uniq -c | sort -n

to see if you have many authentication failures from any IPs.  If so, your account is being brute-force attacked. Block the offending IPs in your server firewall.

–> Use secure passwords for your email accounts. Check out the various domains and make sure there are no test accounts created. Under normal cases, test email accounts are created with insecure passwords, which can easily be guessed by the attacker.