Re: CGI, fork, long processes on Apache 2

The code you provided isn't very helpful. Are you saying that the script itself fails, or that the script works in the background, and the web page won't refresh? There is a big difference, and there are very different answers to each question.

I'd bet that what you're talking about is that the web page isn't refreshing since it is browser specific. If this is the case, you need to check how you're making the page refresh. Are you using a refresh header, a META refresh tag, or javascript? The best thing to do is javascript, because IIRC some browsers don't refresh until the page completely loads. The problem with this is that there are known issues with forked long running cgi scripts under Apache 2.0.x, that mean that the web page will never load.

What you should do is create a tag just like this in your web page:

<script>
// use GET or cookies if you need to post any info
document.location = "your web site";
</script>
[download]

Because javascript is loaded before the web page finishes loading, it should work well. And you should have it point to a web page with a META refresh tag, or refresh header, or create a javascript script to refresh at the proper interval. Also, always keep a refresh tag / header in the first page you send out -- just in case the client has javascript turned off. Also, if you want to save on server load, it is possible to write a javascript script to fetch a number (percent complete), display it, and then post the results when everything is done. I know creating a page that refreshes in Perl might be easier, but if you have a very high server load it can save you significant bandwidth (just sending 2 - 3 bytes in charachters for the percent done versus entire web pages)

Hope that helps,

Vautrin

Want to support the EFF and FSF by buying cool stuff? Click here.

Comment on Re: CGI, fork, long processes on Apache 2 Download Code

Replies are listed 'Best First'.
Re: Re: CGI, fork, long processes on Apache 2 by Anonymous Monk on Apr 03, 2004 at 20:12 UTC
The code you provided isn't very helpful. Are you saying that the script itself fails, or that the script works in the background, and the web page won't refresh? There is a big difference, and there are very different answers to each question. print $query->redirect("New URL goes here"); The script doesn't fail, it's the redirect header that's not being honored by the browser because Apache hasn't dropped the connection. The redirect will go through once the process ends (a good three or four minutes later.) To shortcut that wait, I fork and the parent dies. Now that I've re-read your post a couple of times, I like that you presented a viable alternative to my redirect/fork trick. Why not print a page to the browser asking it to refresh itself to the page I want? That's so simple and obvious compared to redirect/fork. I'll try it and post back when it works. Thanks as well for the Javascript update % idea. I wasn't aware that Javascript could reach out to the web and read in another page outside the current one. Javascript gives me the willies though because of how difficult it is to make a script work in every browser. Maybe I'll take a look at it again in the near future.	[reply]
Re^2: CGI, fork, long processes on Apache 2 by Anonymous Monk on Apr 03, 2004 at 23:36 UTC
I'm not really sure about this, but does your script close STDOUT and STDERR (and possibly repoen them to /dev/null) after the redirect is printed out? This will tell the browser to see a closed connection and it won't wait for anything more.	[reply]
Re: Re^2: CGI, fork, long processes on Apache 2 by Vautrin (Hermit) on Apr 04, 2004 at 20:20 UTC
There is a bug in Apache 2.0.x. If you have a long running CGI script you'll see an error in your CGI logs: `The timeout specified has expired: ap_content_length_filter: apr_bucket_read() failed`. This is why his script works properly under apache 1.3 and not 2.0.x -- because under Apache 2.0.x there comes a point where it just won't die. Want to support the EFF and FSF by buying cool stuff? Click here.	[reply] [d/l]