How to Use Disk Quotas in Dedicated Linux Servers for cPanel Servers

Part two of my full original article on handling disk quotas on various server types. Quotas are a critical component of shared webhosting and understanding how to utilize them is paramount to anyone administrating web servers.

Article Name: How to Use Disk Quotas in Dedicated Linux Servers for cPanel Servers

Published: 2018-05-21
Publisher: Liquid Web Knowledge Base
Author: Jason M PotterThe cPanel Guy

The nightmare that is wp-cron.php

One major gripe I have with WordPress is the default wp-cron.php implementation. If you are familiar with how WordPress uses wp-cron.php by default, you may want to skip ahead to the next section of this article.

What is wp-cron.php & How does it work?

The file wp-cron.php is the portion of WordPress that handles scheduled events within a WordPress site. Anything that has to do with scheduling posts or publications and really anything date/time oriented is governed by the wp-cron.php file.

In order for wp-cron.php to work properly, it needs to be executed frequently, but no more than once per minute. However, the default behavior does not require you to set up a real system level cron job on your server. Instead, it uses a piggyback method on every incoming request. When a request comes into the site, WordPress will generate an additional request from itself to the wp-cron.php file over HTTP(S). That sounds pretty innocuous, right?

Why is the default wp-cron.php behavior a nightmare?

The default method works perfectly fine on a small site with very few visitors per hour.  However, when implemented on a medium or larger site or even a site that is being scanned by bots (which is very common these days), this means you get twice fold whatever traffic you are currently handling. It becomes a rudimentary DDoS attack against yourself. This is because the cron is being executed multiple times a minute using an HTTP request. The HTTP request generates additional overhead by having to generate, negotiate and establish the connection over a network socket. It even impacts the effective capacity of your underlying web server. This solution does not fare well in most situations, and honestly, it should be removed as the default behavior due to its propensity to be abused or turned into an attack vector on a server just from regular traffic.

Well, what are the alternatives?

The only real alternative and the much better solution is to configure a regular system cronjob that executes the wp-cron.php script directly through PHP every minute. This ensures that any scheduled tasks are indeed executed at their scheduled time. It also should not be done via an HTTP request but a direct execution of PHP to avoid hindering the web server’s capacity or generating additional memory overhead on the network layer.

How do I disable the default wp-cron.php behavior?

This is pretty universal and simple to do. You need to update your wp-cronfig.php file to include the following setting:

define('DISABLE_WP_CRON', true);
  • You can typically find your wp-cron.php file in your site’s public_html directory.
  • The setting should be put near the top of the page with the other initial settings.

How do I set up a system cron job?

This is simple in cPanel, assuming your hosting provider has enabled the cron job feature on your account.  The cPanel Cron Jobs Documentation goes into greater details but essentially you do:

  1. Login to cPanel for your domain: yourdomain.tld/cpanel
  2. Input “cron” in the quick search box near the top of the page.
  3. Click “Cron Jobs” icon that appears.
    • If it does not appear, your account does not have the Cron Jobs feature enabled and you will need to talk to your hosting provider for help setting up the cron or switching to a package that includes the Cron Jobs feature.
  4. Pay attention to the Cron Jobs page, it will provide you the exact location of your PHP binary. You will need to copy that path into the command box at the bottom of the page and alter the file being executed by PHP to be your /home/username/public_html/wp-cron.php file instead. Using the full path.
  5. Select the first entry (“*”) for each parameter. This will execute the wp-cron.php file every minute.
  6. Click that add cron button and you’re done.


Why are you so harsh on this practice, it seems reasonable and easy to fix?

I believe it is up to the software engineers that develop our digital world to impress upon themselves a sense of responsibility for their products. WordPress is ubiquitous these days and with auto installer software, like Softaculous, WordPress gets installed on a very large majority of sites. They are installed with the default behavior enabled, which is essentially an attack vector on any server. Now with the hosting industry being so prevalent in our lives, many people have WordPress sites and do not know about this issue until it cripples their site. The default integration is sorely inadequate and should be removed. Today on one server alone, I found over 500 different installs of WordPress and watched as a bot hit each site on the server. Every one of those sites suddenly became a liability for the server’s stability.

I realize that this problem is handled on a case by case basis. However, with so many installs around the world, it would be better addressed by WordPress rather than every single hosting provider who has to set up special conditions on their server to protect against the hole this software generates. The cost of removing this behavior and forcing site owners to generate a system cron should be baseline and a notice placed within the WordPress admin interface that scheduled tasks will not be executed until a system cron job is created properly. This is within my programming skills, so I know it’s well within theirs.

WordPress aims for ease of use, so their target consumers are those that typically know little about hosting caveats.  I believe the responsibility here lies entirely with WordPress to fix and they have taken the stance against it. In the meantime, the System Admins in the hosting industry have to suffer through this terrible “feature” when examining servers that have fallen out of control due to a bot running over a default WordPress install.

How to Use Disk Quotas in Dedicated Linux Servers

This piece is taken from a broader article I wrote discussing quota usage and some of the unsung dangers that can occur when disk space runs low. The original covers both Linux Plesk and cPanel servers, those particular parts of the original source will be published as their own articles.  As always, you can find all my currently published articles with other parties on the External Publications page here on

Article Name: How to Use Disk Quota in Dedicated Linux Servers
Published: 2018-05-17
Publisher: Liquid Web Knowledge Base
Author: Jason M PotterThe cPanel Guy

Understanding Liquid Web’s High Availability cPanel/KVM Servers

Why didn’t the HA-cPanel/KVM kick-in when Apache was down for 20 minutes?

Apache operates on the service level of the HA-cPanel/KVM infrastructure. Service levels issues are not monitored. This is because they are contained within the virtual machine running on within the virtualization layer. Quite simply, the underlaying parent servers have no idea what is running on the guest VM they are protecting. Consider the following simplified chart of a typical HA-cPanel/KVM setup:

As we can see the LAMP Stack where Apache resided is further up past the Fail-safe level. There guest server runs in its own virtual environment. It’s not even aware that it is a guest in the environment and behaves like a standard Virtual Machine.

The HA-cPanel/KVM hardware layer protection is constantly at work. Each parent is perpetually talking to each other over a dedicated cross-over cable using a heartbeat daemon.  The moment the PRIMARY server fails to identify itself to the SECONDARY server, the SECONDARY server springs to life, promoting itself to PRIMARY and spinning up the virtualization platform to launch the guest-vm.

Fail-over is not completely seamless in this configuration. The guest-vm must be booted up on the new PRIMARY parent. However, due to the constant synchronization of data using DRDB  there should be minimal lost data.

Why not monitor the service level?

That’s a tricky questions. Fail-over in this system is designed to protect against imminent hardware failure and not a system built to maintain service uptime. Service level issues are generally resolved without needing to reboot a server. Since fail-over is effectively an abrupt power off of the guest-vm, it’s not a clean shutdown and there is always a minimal risk of some data loss or corruption.

There are better suited configuration for handling service level downtime. A highly trafficked site can take advantage of Load Balancing techniques to ensure responsive and stable uptime of their Apache LAMP stack. HA-cPanel/KVM can also work as a single node in an LB setup offering both the service level stability of a Load Balancer as well as the hardware level protection of HA-cPanel/KVM. You can have the best of both worlds.

If you are looking for a reliable system that protects against hardware level damage, give the folks at Liquid Web a few moments of your time to consider a solution like this for your valued data. I promise they won’t bit and the support is truly heroic.