(bbq) Re: tracking files

I suppose that the question is actually if there is a way to log when CGI (using ActivePerl) goes bad under NT. Correct? I guess this is another "it depends" question.

To the best of my (limited) knowledge, this is much more of a webserver issue than it is an OS issue. Since IIS is somewhat tied up to NT (and vice-versa), consider the following:

IIS The webserver spawns the process, which gobles memory, CPU, the machine crawls to a halt, and before the script can timeout, or write a bad line to the error logs, the server is dead. Sounds familiar? I've never found a way around it, except for:
Apache Acording to the documentation it runs as "experimental" on the NT boxes, but it kicks IIS but when it comes to respecting the process it spawned. Instead of using up all of the servers' CPU and memory, it will promptly timeout the process, and return a 500 to the browser (after a while). Since we are on the webserver comparison issue, may I also note that Apache on NT implements SSI correctly, and not that sorry excuse for server-side includes that MS named SSINC.DLL

Bottom line? There's probably some way to do it with IIS, but I'd drop it in favor of a better webserver if possible. If it isn't possible, there must be some way to shorten the timeout period by tweaking the registry or something of the sort. I prefered not to go there. Trying to implement this from within the CGI sounds even more troublesome. If you're going to open each and every script, you might as well track down the faulty one and remove the infinite loop.

My US$0.02.

#!/home/bbq/bin/perl
# Trust no1!

Comment on (bbq) Re: tracking files

Replies are listed 'Best First'.
Re: (bbq) Re: tracking files by clintp (Curate) on Dec 03, 2000 at 23:08 UTC
I'd like to add some support to this. We're developing a rather hairy application under IIS. Essentially, it's a 15-year-old single-user DOS application that we're web-enabling. We're mucking around in this ancient code to put XML interfaces everywhere to its API so we can get to its internal structures. Perl is the glue binding all of this together. Progress is slow, and failures tend to be spectacular as doing CGI and XML processing in C is No Fun (tm). Sometimes the backend throws an "APPLICATION ERROR" (segfaults), sometimes it just...spins off and never quite stops running, sometimes it just stops. All of these cause IIS to have hissy fits and the development machines have to be rebooted completely to get rid of the rogue processes. We've discovered that it's FAR easier to fire up Apache in a command-window as a development environment and then port to the IIS system for testing. We wind up with better code (portability!) and since Apache is a user process, its children can all be killed with the process monitor. Things go awry, we simply click in Apache's window, ^C, wait and restart it. If things bugger up completely, we kill Apache and then hunt down the errant process and kill it with the process monitor.	[reply]
Re: (bbq) Re: tracking files by rrwo (Friar) on Dec 04, 2000 at 18:55 UTC
There is a way to do it with IIS. You need to configure the application to run under the IWAM rather than IUSR account but telling it to run as a separate process. If it crashes it will not take down the rest of the server. You can use the MetaBase editor (downloadable from Microsoft's web site... do a search for "MetaEdit" in the knowledge base) to configure the number of times it will be restarted in the `AppOopRecoverLimit` key when it crashes (default is 5... set it to something much higher if you'd like). That said, take a closer look at your scripts. I find scripts which use GD or which use DBI with a large LongRealLen value are more crash prone. Also, scripts which use DBI and do not properly finish statement handles are also crash prone, especially if the SQL query sorts large amounts of data.	[reply] [d/l]


Perl: the Markov chain saw
	PerlMonks