Rewrite the script so it is not so likely to hang or at least returns a message that it could not complete.

If the script is likely to hang, it is also likely that your user's work is not completed. I doubt they will appreciate getting a message that says it is, when it isn't.

Mail::Sendmail is probably a good place to start. There are examples of how to use it there, and a Super Search here will almost certainly turn up others.

Starting a long running task from a web server is a reasonable, though unusual, thing to do. I did it once about 10 years ago on a Linux system.

In my CGI script (in Perl), I included something like:

# define the task
my $task = <<'_EOT_'; # use ' to prevent interpolation
#!perl -T
# use -T to specify taint mode
use strict;
use warnings;
# (your processing goes here)
# (generate and send notification - suggest using Mail::Sendmail)
__DATA__
_EOT_
# append the data
$task .= join "\n", @data;
# save the task
open my $tf, '>', $tmpfile;
print $tf $task;
close $tf;
# submit the task
system('batch', '-M', '-f', $tmpfile);
# (tell user the task has been submitted)
[download]

Note that I used an often neglected feature of Linux/Unix/POSIX - the batch command. This command is usually part of the "at" package, so if batch is not available on your Linux/Unix/POSIX computer, that's what to install.

FYI, the batch command queues the specified task when the machine is not too busy. Tasks in the queue will be run in the order they were queued.

If you can't use batch (or similar), try:

system("nohup $tmpfile &");
[download]

But using batch will reduce the risk of overloading your server.

Starting a long running task from a web server is a reasonable, though unusual, thing to do. I did it once about 10 years ago on a Linux system.

Is the task still running? ;-)
لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

Starting a long running task from a web server is a reasonable, though unusual, thing to do.

Perlmonks standard link for that problem: Watching long processes through CGI

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

"At and batch as presently implemented are not suitable when users are competing for resources. If this is the case for your site, you might want to consider another batch system, such as nqs."

The user will be patient for about 20-30 seconds if you warn them about this in advance. Without any warning at all, the folks will just give up and cancel the browser session if the time goes past that. That frustrates everybody! They are angry and this burned a lot of Mips on your server to no result. Everybody is mad.

The idea of not producing a result at all is bad! WOW!
That is an incredibly bad idea!
Your program should produce a result, even if that result is "I can't produce a result".

I sometimes work with some large DB's on line, like the FCC, U.S. Federal Communications Commission (FCC.gov). I can submit a complex DB query and I give them an email to send the reply to. After maybe 30 minutes, I get a URL via email that allows me to download my results. That URL and the data "expires" after some amount of time (24-48 hours or so). This idea works very well for complicated things.

Of course the best thing is to be performant and generate a quick response, but that is not always possible.

This is a fairly common practice in sites that generate custom PDFs. I've seen it for book purchases that apply a watermark to the book so it's got your name on it and also on proposal sites where part of submitting a proposal is to generate a pdf from the submitted materials.

Exactly how you do it depends on the level of security you want for the content generated for the user. The easiest and least secure is to generate a file, write it to the webserver in a place that's accessible to all visitors and then send a link to the user with Mail::Sendmail. You can obfuscate things a little by using a hash function to generate unique and unpredictable filenames and not allowing the directory to be listed, but it's still relatively insecure.

More secure is to generate the file and store it someplace that your scripts are allowed to read, but isn't accessible in the webserver directory structure. Then you generate the file and store it in the storage directory and record that location in a database. You also create a URL that you store in the same directory database (or that lets you figure out where you stored the user's file, e.g. a url that calls http://example.com/cgi/downloader.pl?file="customdownload.pdf") send the link and a nice note. Then when the user calls your website with that URL it executes the script that passes them the file. If you want it to be secure, you require the user to be logged in to get the file.