|
Home > Archive > Apache Server configuration support > November 2006 > CGI-BIN Forced Termination (Apache)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
CGI-BIN Forced Termination (Apache)
|
|
| David T. Ashley 2006-11-20, 1:31 am |
| I've noticed that some scripting languages (PHP, for example) have options
to control whether the script can be terminated by the user clicking STOP on
their browser (or similar mechanisms).
How does this apply to CGI-BINs? Can Apache ever try to terminate a
CGI-BIN, or does it just keep running and its output is discarded? Is there
any signalling?
| |
| petersprc 2006-11-20, 1:31 am |
| As far as I know, in the event of a disconnect, Apache will send a
SIGTERM to the child, and then, if needed, wait up to approximately 3
seconds and send a SIGKILL. Your CGI could handle the SIGTERM and do
any required cleanup. It could also leave behind a long-running process
using the "at now" command.
Some more info here:
http://mail-archives.apache.org/mod...l@apache.org%3E
David T. Ashley wrote:
> I've noticed that some scripting languages (PHP, for example) have options
> to control whether the script can be terminated by the user clicking STOP on
> their browser (or similar mechanisms).
>
> How does this apply to CGI-BINs? Can Apache ever try to terminate a
> CGI-BIN, or does it just keep running and its output is discarded? Is there
> any signalling?
| |
| David T. Ashley 2006-11-20, 1:18 pm |
| "petersprc" <petersprc@gmail.com> wrote in message
news:1163999132.953698.153670@h48g2000cwc.googlegroups.com...
> As far as I know, in the event of a disconnect, Apache will send a
> SIGTERM to the child, and then, if needed, wait up to approximately 3
> seconds and send a SIGKILL. ...
Thanks. The info was very helpful.
The hard part for me is that I've searched all over the web and found
various documents that outline the stdin/stdout interface, but process
termination was not discussed anywhere I've found. That seems odd, because
SIGTERM and SIGKILL are part of the interface.
If you can recommend any good books or authoritative references ... I'm just
getting started (never written a compiled 'C' CGI-BIN before ... have just
used scripting languages like PHP, and nearly all of that is handled for
you).
| |
| petersprc 2006-11-21, 1:31 am |
| If it's a C program, using a library like this might simplify things:
http://www.boutell.com/cgic/.
If you haven't been here yet, there's an overview of Apache CGI at:
http://httpd.apache.org/docs/1.3/howto/cgi.html.
For internals, you may want to take a look at mod_cgi.c in the Apache
source...
David T. Ashley wrote:
> "petersprc" <petersprc@gmail.com> wrote in message
> news:1163999132.953698.153670@h48g2000cwc.googlegroups.com...
>
> Thanks. The info was very helpful.
>
> The hard part for me is that I've searched all over the web and found
> various documents that outline the stdin/stdout interface, but process
> termination was not discussed anywhere I've found. That seems odd, because
> SIGTERM and SIGKILL are part of the interface.
>
> If you can recommend any good books or authoritative references ... I'm just
> getting started (never written a compiled 'C' CGI-BIN before ... have just
> used scripting languages like PHP, and nearly all of that is handled for
> you).
| |
| Tim Roberts 2006-11-21, 1:31 am |
| "petersprc" <petersprc@gmail.com> wrote:
>As far as I know, in the event of a disconnect, Apache will send a
>SIGTERM to the child, and then, if needed, wait up to approximately 3
>seconds and send a SIGKILL. Your CGI could handle the SIGTERM and do
>any required cleanup. It could also leave behind a long-running process
>using the "at now" command.
Is that promised anywhere? In my experience, the only side effect of the
disconnect is that the sockets feeding stdin and stdout get disconnected.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
| |
| David T. Ashley 2006-11-21, 1:20 pm |
| "Tim Roberts" <timr@probo.com> wrote in message
news:ks95m2p4aa4eo09eqv0ngiv9vaju8jvtdd@
4ax.com...
> "petersprc" <petersprc@gmail.com> wrote:
>
>
> Is that promised anywhere? In my experience, the only side effect of the
> disconnect is that the sockets feeding stdin and stdout get disconnected.
Ah, and then we're back again to my weak Unix programming skills.
If the stdin socket gets disconnected, I have no idea what will happen (will
it look like an EOF?). I suppose the cgic library takes care of this part
....
But if the stdout gets disconnected, can my CGI-BIN just go blindly using
printf()'s with no ill effects??? ... I'd guess yes.
But in any case, good references would be always be appreciated. I actually
know nothing about sockets and so forth, except that they exist.
| |
| petersprc 2006-11-24, 1:32 am |
| I think a SIGPIPE starts it, and then mod_cgi will detect that it needs
to follow with a kill.
Tim Roberts wrote:
> "petersprc" <petersprc@gmail.com> wrote:
>
>
> Is that promised anywhere? In my experience, the only side effect of the
> disconnect is that the sockets feeding stdin and stdout get disconnected.
> --
> Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.
| |
| petersprc 2006-11-24, 1:32 am |
| It looks like you won't get the SIGPIPE unless you try to write (or
read) from the closed socket. So, your CGI will probably continue until
it attempts some I/O.
petersprc wrote:[vbcol=seagreen]
> I think a SIGPIPE starts it, and then mod_cgi will detect that it needs
> to follow with a kill.
>
> Tim Roberts wrote:
| |
|
|
"petersprc" <petersprc@gmail.com> schreef in bericht
news:1164341247.373881.17910@h54g2000cwb.googlegroups.com...
Fragments refering to this sequence can be found in the source files of
various modules.
I am unsure whether those apply to handling lost connections or are just
propagating a SIG* to all forked children, CGI included. Chances are
mod_cgid behaves slightly different.
[vbcol=seagreen]
I have seen the same effects.
[vbcol=seagreen]
>I think a SIGPIPE starts it, and then mod_cgi will detect that it needs
> to follow with a kill.
Fragment of source code seem to contradict:
* Note that we already ignore SIGPIPE in the core server.
unix/posix notes:
- The proper setting for SIGPIPE is SIG_IGN, if user code changes it
for any of their own processing, it must be restored to SIG_IGN
prior to executing or returning to any apache code.
The latter may indicate behaviour depends on OS.
HansH
| |
| R Krause 2006-11-29, 7:24 pm |
| David T. Ashley wrote:
> I've noticed that some scripting languages (PHP, for example) have options
> to control whether the script can be terminated by the user clicking STOP on
> their browser (or similar mechanisms).
>
> How does this apply to CGI-BINs? Can Apache ever try to terminate a
> CGI-BIN, or does it just keep running and its output is discarded? Is there
> any signalling?
Excellent question. Unfortunately, Apache's behavior in exceptional
circumstances like this is not very well documented (and is one of my
biggest gripes  Most of what I know is from experimentation and
perusing the Apache source code.
As was pointed out earlier, Apache responds to a SIGPIPE, by issuing a
SIGTERM to the CGI, then sleeping for three seconds, and then issuing a
non-interruptable SIGKILL. However, take note that Apache won't receive
the SIGPIPE unless you are writing to STDOUT (this is fairly standard
behavior with socket communication). This means that if the client
disappears while the CGI is performing a time-intensive operation,
there will be no notification of the disconnected socket until after
the CGI again writes to STDOUT. Additionally, if the CGI exceeds
Apache's configured timeout between successive writes to STDOUT, then a
SIGTERM will also be issued.
By not catching (or ignoring) the SIGTERM in either of these two
scenarios, your process will simply be terminated. About the only way
to be reasonably notified of a disconnected socket is to keep writing
to STDOUT. (It may even be possible to write nothing, which could force
a flush of the internal buffer, but I'm not entirely sure if that
actually works.)
--Randall
| |
| David T. Ashley 2006-11-29, 7:24 pm |
| "R Krause" <rkrause@searstower.org> wrote in message
news:1164839811.133397.238510@j72g2000cwa.googlegroups.com...
> Additionally, if the CGI exceeds
> Apache's configured timeout between successive writes to STDOUT, then a
> SIGTERM will also be issued.
I've never noticed this configuration directive anywhere. Do you remember
the name? Is it compile-time or in the config file?
Thanks, Dave.
| |
|
| "David T. Ashley" <dta@e3ft.com> schreef in bericht
news:Mbobh.378$497.302@fe74.usenetserver.com...
> "R Krause" <rkrause@searstower.org> wrote in message
> news:1164839811.133397.238510@j72g2000cwa.googlegroups.com...
>
> I've never noticed this configuration directive anywhere. Do you remember
> the name? Is it compile-time or in the config file?
>
The name is ... timeout ...
http://httpd.apache.org/docs/2.0/mod/core.html#timeout
.... it's setting matches the impatience of a browser: 5 min
IIRC a script will be killed at the next write to STDOUT following the
timeout period
Limiting the cpu time consummed before complition might eventualy kill a
'silent' script. However, e.g. a script waiting for response from a database
may NOT consume any CPU time (In addition set a timeout per handler for
statement and|or database)
http://httpd.apache.org/docs/2.0/mo....html#rlimitcpu
HansH
| |
| R Krause 2006-11-30, 1:36 am |
| petersprc wrote:
> As far as I know, in the event of a disconnect, Apache will send a
> SIGTERM to the child, and then, if needed, wait up to approximately 3
> seconds and send a SIGKILL. Your CGI could handle the SIGTERM and do
> any required cleanup. It could also leave behind a long-running process
> using the "at now" command.
>
> Some more info here:
>
> http://mail-archives.apache.org/mod...l@apache.org%3E
Excellent link. That's still one of my fave bug reports for Apache 1.3.
It's interesting to think it was submitted in 2001 and yet that feature
has still never been implemented properly to date.
Btw, I'd never heard anyone suggest 'at now' before. That sounds like a
very suitable workaround. I'll have to give it a try.
--Randall
|
|
|
|
|