My issue was the user with the cronjob did not have access to run the cronjob php file. So, I needed to make the new cronjob for the correct user.
Solution:
Find out the owner of your apache process (usually www-data).
Look at the top of the “Automation Settings” page in your WHMCS admin area. It should say something like: php -q /var/www/whmcs/admin/cron.php (keep this handy for step 4)
In terminal run: crontab -e -u www-data
Ensure you have a line that says: 0 6 * * * php -q /var/www/whmcs/admin/cron.php (note: this should be the same file path you got for your own install in step 2)
The DLL load failed error happened when cherrypy tried the following import: from OpenSSL import SSL
ChannelFailures: VerificationError("importing 'C:\\\\Python27\\\\lib\\\\site-packages\\\\cryptography\\\\_Cryptography_c
ffi_48bbf0ebx93c91939.pyd': DLL load failed: %1 is not a valid Win32 application.",)
I purchased a chinese access controller and reverse engineered some functionality of the windows software that came with it. I made a python library that does some of the same functions as the desktop software: https://github.com/pawl/Chinese-RFID-Access-Control-Library/
I use this library to tie our access controller into with our billing system (called WHMCS) and another web application (which is meant to be a self-documenting way to activate/deactivate RFID badges): https://github.com/pawl/MakerManager
Now, whenever someone stops paying for 5+ days, their RFID badge is deactivated because a “hook” in WHMCS sends a request to a webservice that uses the access control library.
Update: We switched to Prefork apache and have been experiencing significantly fewer problems.
In this instance, we were getting hit with web crawlers according to the access log and the syslog was saying this: /usr/sbin/apach invoked oom-killer
This issue occurs when apache opens up too many child processes, uses up too much memory, then OOM killer starts shutting down random processes like mysql.
The problem ended up being that our apache2.conf did not have any configuration limiting the number of processes that Apache could open. It might have had a default, but the default was too high. We were using Apache ITK MPM and the apache2.conf only mentioned prefork, worker, and event MPMs. You can check which MPM you are running with “apache2 -V”.
Adding this to the configuration solved the problem:
At first I had the ServerLimit and MaxClients set to 150 and it seemed like apache was ignoring ServerLimit and Maxclients. However, ITK MPM creates an extra fork for each request (according to their site), that’s why there was 200+ processes running for my limit of 150. So, the process count is going to be 2x the limit you set.