Jan 082010


When I started this blog, I started it for my own benefit so I could remember those little tweaks or fixes which escape memory at crucial times when a needed repair or a new issue arose that I had never dealt with before. When I would research these issues, I would come across great posts and information I wanted to remember and posted that information here. If I did not give credit where credit was due regarding those posts and if you find something that was posted by you, please let me know and I will credit the post to you. I cannot remember where I pulled all of the information from so, if you see something that is yours, do not fret, I am not stealing your shtuff, I am posting it so all can read and learn from the mistakes and information I have gathered. Most of the posts are mine, but not all. Thank you all for your patience and information you have shared to better improve the linux experience.

Oh and by the way, if you see a post that has outdated or incorrect information, please, please, pretty please let me know so I can update it. Believe it or not, I use this site also and I want my information to be up to date as well. Thanks again for visiting.

Share This!
 Posted by at 7:57 pm
Feb 122017

Howdy all!

There looks to be a bug with cPanel 11.62 and EasyApache 4 which causes Softaculous to fail when attempting to install software. You will probably see an error in Softaculous stating that it can’t connect to MySQL. You will also see something like the following in cPanel’s error log.

cPanel LiveAPI parser returned XML, which is deprecated. Please file a bug report at https://tickets.cpanel.net/submit/
sh: /opt/cpanel//root/usr/bin/php: No such file or directory
[2017-02-09 17:14:04 -0500] warn [cpaneld] The subprocess (cpanel (cpanel)) exited with an error: The subprocess ended prematurely because it received the “SEGV” (11) signal. The process dumped a core file. at /usr/local/cpanel/Cpanel/Server/Handlers/SubProcess.pm line 159.
Cpanel::Server::Handlers::SubProcess::_report_subprocess_errors(Cpanel::Server::Handlers::SubProcess=HASH(0x2b7b180)) called at /usr/local/cpanel/Cpanel/Server/Handlers/SubProcess.pm line 74
Cpanel::Server::Handlers::SubProcess::handler(Cpanel::Server::Handlers::SubProcess=HASH(0x2b7b180), "subprocess_name", "cpanel (cpanel)", "subprocess_read_handle", IO::Handle=GLOB(0x2b7afa0), "subprocess_write_handle", IO::Handle=GLOB(0x2b7af88), "api_type", ...) called at cpsrvd.pl line 6476
    cpanel::cpsrvd::cpHandler("app", "cpanel", "document", "./frontend/paper_lantern/softaculous/index.live.php") called at cpsrvd.pl line 2363
    cpanel::cpsrvd::dodoc_cpaneld() called at cpsrvd.pl line 1607
    cpanel::cpsrvd::dodoc(HASH(0x13a7770)) called at cpsrvd.pl line 1314
    cpanel::cpsrvd::handle_one_connection() called at cpsrvd.pl line 849
    cpanel::cpsrvd::script() called at cpsrvd.pl line 319

This is a known bug in cPanel 11.62 that was in line for repair, but apparently is still an issue.
Softaculous pushed an update which provides a work-around for this. You should be able to update Softaculous by running its cron.php.

/usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/whostmgr/docroot/cgi/softaculous/cron.php

The version with the workaround should be 4.8.8.

Share This!
 Posted by at 8:51 am
Dec 072016

Recently I came upon an issue on a cPanel server with suPHP as the handler in that, when the cPanel user SSH’s into the server (or connects via sFTP) any file or directory created will have incorrect permissions.

  • Files: 664
  • Directories 775
    I found this was due to a setting in /etc/profile that sets the umask value as such

    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
        umask 002
        umask 022

    It has been confirmed by cPanel that this is an internal bug already known that affects suPHP servers.
    Quoted from cPanel

    I found that we have internal case EA-4868 about the same issue you are describing, which is problems with suphp and the umask permissions. I am not able to provide an ETA on when a fix for that will be released, however it will be pushed to our changelog once it is.

    So… if you have a customer that has files that were created via SSH or upload over sFTP, that are getting 664 and 775 incorrect permissions errors? First, check the PHP handler

    /usr/local/cpanel/bin/rebuild_phpconf --current

    If that setting is set to suPHP, then the workaround for this, as recommended by cPanel, is the following:
    Change /etc/profile

    vim /etc/profile

    Locate the if/else statement setting the umask, most likely around line 64

    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
        umask 002
        umask 022
    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
        umask 022
        umask 022

    Save the file, then connect as the user with

    su - $user

    Reload the profile; the new files and directories should be set with the correct permissions.
    As always, back up all the things first!
    Hope this helps!

    Share This!
    Oct 312016


    Do you have a client who says that they cannot access their sites/server and insists it’s a network issue, but their IP addresses does not seem to be blocked by csf.deny and their sites are not loading in several parts of the world with a site checker like https://www.site24x7.com/check-website-availability.html or others?

    Well do I have quite the solution for you!

    This morning, we verified an issue regarding a CSF/Spamhaus update in which CSF blocks any IP address that is over This is due to a subnet that does not exist in the official list,


    Unfortunately, CSF will round the down to which will block all IP addresses above that range. To remedy this, after verifying the subnet issue is present, remove the SPAMDROP list file:

    rm /var/lib/csf/csf.block.SPAMDROP

    And restart CSF

    csf -r

    Restarting CSF will generate a new (and correct) SPAMDROP list without the wonky subnet.

    Now, verify the sites on the server can load now throughout the world without issue:



    Share This!
    Sep 182016
    Hi all,


    I have been noticing quite a few issues relating to the cPanel p0f service crashing and sending e-mail notices to customers. This appears to be related to a recent cPanel update based on early reports. Fortunately, the fix is quite simple and should only require you to run the following commands:
    /scripts/check_cpanel_rpms --fix

    What is the PoF service you ask? Well cpanel says this is the Passive OS Fingerprinting Daemon

    If you are on a CentOS7 server, you also need to create an extra entry to the yum.conf excludes, I have checked and confirmed that this fix does work and should be a permanent solution.


    /etc/yum.conf, add p0f*

    to the exclude line. You can add it to the end if you want. It will automatically sort it in alphabetical order.

    exclude=courier* dovecot* exim* filesystem httpd* mod_ssl* mydns* mysql* nsd* php* proftpd* pure-ftpd* spamassassin* squirrelmail*


    exclude=courier* dovecot* exim* filesystem httpd* mod_ssl* mydns* mysql* nsd* p0f* php* proftpd* pure-ftpd* spamassassin* squirrelmail*

    and then you can run /scripts/upcp and /scripts/check_cpanel_rpms without triggering the issue again. Otherwise at the next upcp the issue will reoccur again and send out more emails about being broken.

    cPanel’s official fix to this is slightly different. They state:  “The issue happens when the EPEL yum repo is enabled. A yum update installs the p0f package from EPEL instead of the cPanel provided p0f package. To correct this, you should added p0f*.el7.* to the excludes line in /etc/yum.conf, and ran /scripts/check_cpanel_rpms –fix to get the cPanel provided p0f package installed. Then you shouldn’t have this issue again.

    So please add “p0f*.el7.*” to the excludes line instead of just “p0f*” as this will prevent this from ever updating at all, while the former entry “p0f*” should only prevent it from updating from non-cPanel sources.

    Share This!
    Aug 162016
    I recently found a specific explanation for why I keep seeing mysql settings being off in my.cnf and causing load issues.
    Recent changes in WHM have added an option to Tweak settings that will allow WHM to determine the “best” settings value. So anytime mysql is restarted from within cpanel, the settings are changed/modified. These settings are on by default.
    • Allow cPanel & WHM to determine the best value for your MySQL open_files_limit configuration?
      This setting’s value defaults to On.
    • Allow cPanel & WHM to determine the best value for your MySQL max_allowed_packet configuration?
      This setting’s value defaults to On.
    • Allow cPanel & WHM to determine the best value for your MySQL innodb_buffer_pool_size configuration?
      This setting’s value defaults to On.
    If you are experiencing load issues of unknown origin, this would be something else to check.
    Documentation can be found at the below link and is current as of Jun 24, 2016
    Share This!