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

Skacc
  • 167
  • 5
  • [Administration panels are off topic](http://serverfault.com/help/on-topic). [Even the presence of an administration panel on a system,](http://meta.serverfault.com/q/6538/118258) because they [take over the systems in strange and non-standard ways, making it difficult or even impossible for actual system administrators to manage the servers normally](http://meta.serverfault.com/a/3924/118258), and tend to indicate low-quality questions from *users* with insufficient knowledge for this site. – HopelessN00b Mar 09 '15 at 08:54

2 Answers2

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

Daniel Widrick
  • 3,488
  • 2
  • 13
  • 27
  • Thanks. I forgot to say I do ignore_user_abort(). I updated my question, sorry. – Skacc Jan 16 '15 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. – Catherine MacInnes Jan 16 '15 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 '15 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... https://www.freebsd.org/doc/handbook/configtuning-cron.html - cron docs – Daniel Widrick Jan 20 '15 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.

Li1t
  • 113
  • 2
  • Thanks. I had this: http://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 '15 at 10:12