2

My problem is that long php scripts (several hours) are exiting early. (FireFox says "connection to the server was reset while the page was loading").

They exit sometimes after 30 minutes, sometimes after 1:45 hour running time.

  • CentOS 6.6 64bit
  • Apache 2.2.9 MPM worker
  • php 5.5.20 mod_fcgid 2.3.9
  • No opcode cache installed
  • cPanel and WHM 11.46
  • I have root access

For FastCGI I included the following to the httpd.conf, via WHM include editor, to post_virtualhost:

<IfModule mod_fcgid.c>
FcgidBusyTimeout 86400
FcgidIOTimeout 86400
</IfModule>

After that IfModule section i have the < Directory path/to/mysite> section (no space after '<').

I use set_time_limit() and ignore_user_abort() many times in the script to keep it running.

There is nothing in apache error logs.

phpinfo: http://lot-art.com/info.php (you can see that set_time_limit() and ignore_user_abort() works)

It worked fine on my older server, that ran mod_php: http://216.119.148.91/info.php

1

2 Answers 2

1

Just run the script seperate of the webserver via cron / etc.

If you need to run it from the webserver... popen(nohup ..) and run the script on the cli...

My guess is the webserver / browser connection times out / fails and eventually the TCP stack says, "We are done here" and the php process gets torn down.. I would hate to imagine a browser window waiting for several hours for a script to complete...

If you really want to do this.. and the problem does turn out to be a client connection issue you could look at setting ignore-user-abort to true in the script / php.ini ...

http://php.net/manual/en/function.ignore-user-abort.php

4
  • Thanks. I forgot to say I do ignore_user_abort(). I updated my question, sorry.
    – Skacc
    Jan 16, 2015 at 16:16
  • 1
    These kinds of things should be run from the command line (through cron or some other tool) not through a browser. At the very least if you really need to initiate it through a browser for some reason put in a wrapper script to fork the process and run in outside of an apache context. Apache workers just aren't meant to run 2 hour scripts. Jan 16, 2015 at 16:21
  • Thanks guys. Im changing the scripts to run in cli. Need advice. I now start it like this: nohup -f script.php args=val > /dev/null 2>&1 &. Is it good like that for cron?
    – Skacc
    Jan 17, 2015 at 10:55
  • cron won't know where your script is. If you want timing activated just add something like 'php /path/to/script parameters > /var/log/myScript.log' to /etc/crontab. If you want to personally trigger the script (IE: via a webaddress) popen the nohup... freebsd.org/doc/handbook/configtuning-cron.html - cron docs Jan 20, 2015 at 16:59
0

Is it possible that this is due to a bug in PHP 5.5? Something like a segmentation fault would cause php to exit immediately - there wouldn't be any error logged AFAIK.

I'd agree that you should probably run it from the command line, if it is a seg-fault or similar then try running it gdb to get a core dump and report it as a bug here: https://bugs.php.net/

If this isn't an option, I'd try adding logging to the task to narrow down at what point the script exits.

1
  • Thanks. I had this: bugs.debian.org/568349 . This would be an issue later when im running real script (not a test script). Im changing the long scripts to run in cli anyway...
    – Skacc
    Jan 17, 2015 at 10:12

Not the answer you're looking for? Browse other questions tagged .