Max_execution_time limited?


#1

I created a site using epiware just to check it out. It’s got a lot of quirks, but I’ve been able to make it work. I had to make my own php.ini in order to stop the “Call-time pass-by-reference has been deprecated” errors in php, which works, for the most part, but when I test for max_execution_time, the script tells me php.ini has it set for “30” not “300”.

This to me says that Dreamhost may be governing max_execution_time another way than php.ini

I’m using the cgi wrapper method for php found here:
http://wiki.dreamhost.com/Talk:PHP.ini

Can anyone confirm?


#2

There is a popular article in wiki to teach people how to install their own php.ini file. Maybe you want to take a look
http://wiki.dreamhost.com/PHP.ini

$50 off and 3 free domains with code: [color=#CC0000]DH3[/color] Sign Up NOW or More Codes Here


#3

Hi Patrick,
Thanks for your reply.

Actually, I have read it.
I also read the discussion about php.ini, as evidenced by the wiki link in my original post.

No mention is made about max_execution_time.

Any ideas?


#4

If you know how to install your own php.ini, it will be very easy to change max_execution_time. Just open your own php.ini and change max_execution_time = 30 (default) to max_execution_time = 300

Did I misunderstand your question?

$50 off and 3 free domains with code: [color=#CC0000]DH3[/color] Sign Up NOW or More Codes Here


#5

Well, last night, when I was trying out my install of php.ini, when I went to check whether it was working:
http://movable.activistinabox.org/cgi-bin/upload.php
Everything passed except for the “max_execution_time” which was still set to “30” even though my php.ini was set to 300.
http://movable.activistinabox.org/cgi-bin/php.ini.txt

I’m using the php5-wrapper.fcgi method, but I notice that when I ‘top’, I get three php.cgi processes as shown below.

[code]Mem: 4075028k total, 3832452k used, 242576k free, 142796k buffers
Swap: 6313512k total, 708480k used, 5605032k free, 1417908k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9312 username 9 0 1660 1660 1224 S 0.0 0.0 0:00.06 bash
12070 username 9 0 1020 1020 844 R 0.0 0.0 0:00.02 top
27385 username 11 2 5708 5704 5512 S 0.0 0.1 0:00.03 php5.cgi
22623 username 11 2 6196 6192 5936 S 0.0 0.2 0:00.02 php5.cgi
3336 username 11 2 6612 6608 5652 S 0.0 0.2 0:00.06 php5.cgi
[/code]So I’m not sure if this is a violation of the TOS, even though it’s suggested in the wiki.

In other words, there are now a few questions:
A. Last night, when I’d set the php.ini and used upload.php to test the settings, the only setting that wasn’t showing correctly was the 300 for max_execution_time. It still showed as 30.

I was wondering if DH was governing max_execution_time from somewhere else, even though I’d created my own php.ini.

B. Is this method creating a persistent process?

C. How do I kill it if it is? ‘k pid’ doesn’t seem to work. It just reestablishes.

When I came back this morning, the processes were gone from top and the site wasn’t working until I tried upload.php a couple times. I actually got a Server Error the first few times.


#6

Just a follow up, in case anyone is interested.

Apparently, this type of persistent cgi is okay with the TOS. They go away after a while. I got that as a reply back from Greg R at DH support. Thanks Greg R!

From outside top, the processes could be killed by ‘kill -9’, but since it’s not necessary, no worries.

Still no idea why max_execution_time wouldn’t show as 300 last night when without changing any settings it does now. Very strange.


#7

Hello,

So it seems that the max_execution_time is set per user ?
Not for each domain or for the whole server ?

Thank you.


#8

I wrote a PHP script first testing locally on my own machine (with standalone PHP php -S localhost:80 -t public_html/) then on Dreamhost shared webhosting account. Here is the PHP script:

<?php
  $start = microtime(true);
  $interval = 2; // Change 2 as you wish
  $last = -1;
  ini_set("max_execution_time", "100"); // Change "100" as you wish
  echo ini_get("max_execution_time")."\n";
  while (true) {
    $time = floor(microtime(true) - $start);
    if ($time % $interval === 0 && $time % $interval !== $last) {
      //echo date("c") . "\n";
      echo date("c") . " " . floor(microtime(true) - $start) . " seconds\n";
    }
    $last = $time % $interval;
  }

With that code (which you can run from command line using curl https://domain.com/path_to_php_script.php), along with existing .htaccess RewriteCond and RewriteRule logic as follows:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://mydomain.com/$1 [R,L]

RewriteCond %{REQUEST_URI} ^(|/|/default.htm)$
RewriteRule .* https://mydomain.com/path [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* https://mydomain.com/path [R=301,L]
</IfModule>

and lastly using PHP 7.x with /home/myuser/.php/7.0/php.ini having max_execution_time = 30

I make the following conclusions (in order of max_execution_time least to most):

  • everything under 90 seconds works as expected (albeit also showing execution times about 0-20 seconds more than set (with 2 second interval, 0-2 seconds incorrect)*

  • PHP script with $interval = 2; and ini_set(“max_execution_time”, “90”); outputs data as expected (as described above)

  • PHP script with $interval = 2; and ini_set(“max_execution_time”, “95”); outputs data as expected (as described above)

  • PHP script with $interval = 2; and ini_set(“max_execution_time”, “99”); outputs data as expected (as described above)

  • PHP script with $interval = 2; and ini_set(“max_execution_time”, “100”); outputs data as expected (as described above, but only sometimes (most of the times, increase max_execution_time more and sometimes is less and less), notice this is just 1 second more than line above) **

  • Even the 0-2 seconds inaccuracy is not accurate, and it seems from several tests running the same PHP values such as $interval = 2; and ini_set(“max_execution_time”, “90”); for example, shows run times of variable lengths, and this is also noticeable where decreasing or increasing the max_execution_time may show longer or shorter run times than the previous length, which seems relatively strange, but otherwise suggests that max_execution_time is inconsistent, but otherwise it is relatively reliable to last at least the given length of time, as long as not exceeding a certain amount, which can be observed from your own tests or shown in the examples above (about 100-120 seconds seems to be hard cut off?)

** With .htaccess rules specified above, when the PHP script does not output data, what is returned from curl ... is HTTP 301 Moved Permanently HTML output such as below:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://mydomain.com/path">here</a>.</p>
</body></html>

I began to investigate this because I had written some php scripts for CRON purposes, that seem to not work with Dreamhost as they did with other service providers, and also locally on my own development environments, and was determined to figure out if there is any work-around. Particularly, I am interested to figure out if it is possible to run a non-public PHP script for 300 seconds, or 600 seconds once every 24 hours. As of yet, I have not found a working solution.

Update: Also, 99 seconds also includes sometimes not working (like 100 seconds), and maybe even 98 seconds and less, but I’m not going to extensively investigate the exact length of time which always works 100% of the time. Instead I’d like to figure out why or if it is possible to run PHP scripts longer than this. For documentation purposes this post is here, and now I shall proceed in bringing this to attention of Dreamhost tech support.

From support:

Also, I was running the PHP script above with 95 second max_execution_time with empty while (true) { } loop, and 49 of 50 times the script completed without being killed, only 1 time, the script was killed (from procwatch as described in the chat above) resulting in htaccess rules triggering 301 redirect.


#9

I wish they’d just partner up with someone who does. Gmail used to be doable until Google did away with the free plan.