Cloud Sites Timeout on CMS Install
Timeout message

Timeout message

Load balancers usually have a limit on how long a TCP connection will remain open to a web server before timing out on the connection. With Cloud Sites in particular, the load balancer will time out on an HTTP response if the PHP code does not send output to the browser for 30 seconds. After this timeout, the load balancer will send its own HTML error page instead of the PHP output. The code will continue to run and generate its HTML output, but the HTML will not be sent to the browser as the TCP connection was already closed when the browser was presented with the error message.

A web page will normally load in much less than 30 seconds as websites that take 30 seconds to load a page would be nearly unsurfable, so this timeout rarely becomes an issue, however some administrative tasks may take longer than this to complete.  One case where this is particularly obtrusive is with some install wizards.  During installation, it is not uncommon to have the PHP for a page perform a number of time intensive tasks totaling to over 30 seconds.  Some CMS installers will resume by refreshing the page, though most will start over. If the operation just needs to run once, you may consider running the install on a server and then migrating the installed site to the production environment, however this isn’t always an option.

To have a page run for longer than 30 seconds, data must be occasionally sent back to the load balancer.  Normally the PHP interpreter will store the HTML output of the PHP script in a buffer until the script is completed, but you can send the contents of the buffer to the browser using the PHP flush() function.

The following script runs for 45 seconds and keeps the connection open by flushing its output to the browser, though this may not be noticed within the browser itself as the browser would typically buffer as well.


if (ob_get_level()==0) ob_start();
for ( $i = 0; $i < 45; $i++) {

By inserting print(" "), ob_flush(), and flush() to a php script, the timeout can be avoided.

With Prestashop in particular, the installer usually stops at the database creation and language installation setting from a JQuery HTTP request taking longer than 30 seconds to complete.  installDefaultData() in install/models/install.php is the primary function to handle this step of the install process.  To prolong the timeout, all that is needed is to throw a few print() and flush() commands into this function and its subroutines createShop() and installLanguages() like so.


167         public function installDefaultData($shop_name, $clear_database = false)
168         {
169                 ob_end_flush();
170                 print(" ");
171                 flush();
252         public function createShop($shop_name)
253         {
254                 // Create default group shop
255                 print(" ");
256                 flush();
267                 // Create default shop
268                 print(" ");
269                 flush();
283                 print(" ");
284                 flush();
286                 Context::getContext()->shop = $shop;
297                 print(" ");
298                 flush();
300                 if (!$shop_url->add())
320                 foreach ($languages_list as $iso)
321                 {
322                         print(" ");
323                         flush();

These commands will occasionally print whitespace to the JSON output which are ignored by the browser, but keep the load balancer from timing out.

No Comments Posted in Uncategorized
Tagged , , , , , ,
Rackspace Cloud DNS API Interface

This zip file contains a php web application to give a GUI interface to the Rackspace Cloud DNS API. It requires Linux, PHP, and curl be installed on the server it runs on. Just unzip the files and upload them to a web server, then hit them with your browser to get started.

I have built this DNS interface mostly using these two links:

Once you log in, the application gives you the chance to designate a subaccount number. This is useful if using the Clients feature of the Cloud Sites service.


DNS API Record List Screenshot

7 Comments Posted in Uncategorized
Limiting a Cron Job to a specific day of the week in Cloud Sites

The Cloud Sites control panel does not have a built in option to run a cron job only on a certain day of the week. There are cases where you would like a job to only run on a certain weekday such as a weekly mailout or a weekend maintenance script.

There is an option to run every few days, however this option, similar to the cron Linux option it calls to, would work by finding the remainder of the day of the month and dividing it by the number you provide then run the job if this remainder equals 1. So if this was set to run every 7 days and the first day of the month is a Wednesday, then the job will run on every Wednesday of the current month, however it may run on any other day of the week next month depending on which day of the week the next month started on.

In order to run a cron job on a certain day of the week, you can run a check at the beginning of the script to check the day of the week and exit if it is not the day that the job should run on.

The following line can be appended to the top of a bash script for it to check if the day of the week is Sunday and exit if it is not. That way you can run the script every day of the week and it will only actually complete on the day that you designate.

if [[ -z "`date '+%a' | grep Sun`" ]]; then exit; fi

No Comments Posted in Uncategorized