OTRS problem on IIS5 and ActivePerl
We are setting OTRS up on Windows with MSSQL and IIS5. We have done a
manual install and all is going well so far - I would be happy to supply
the database schema files (though we are still adjusting them a little)
for others to use and comments on what we had to do to get it to work.
However we are experiencing a few problems with perl and OTRS - I
realise you guys are not IIS folks and I have posted these problems on
the activePerl forums but wondered if you have any ideas on my problems
- see the discussion below:
Regards,
Michelle Davis
-------- Original Message --------
Subject: Re: IIS Crashes on perl error
Date: Tue, 01 Mar 2005 11:43:02 +1100
From: Michelle Davis
Michelle Davis wrote:
John Deighan wrote:
At 09:46 PM 2/27/2005, Michelle Davis wrote:
Hi All,
We have an ActivePerl setup on WinXP Pro with IIS 5. We have mapped perlis.dll to .pl and everything pretty much works fine. One little problem, if anything is wrong with a script and it generates an error - it writes the error fine to PerlIS-Err.log (took me a while to find this log ;->> ) but (and this is a big BUT) - it also hangs IIS. This means that unless I restart it, no further processing of any webpages can be done with IIS.
Does anyone know how to address this? All I want is for IIS to not crash out as we have to deploy this in a production enviroment and can't have all of IIS going down everytime an error occurs in a Perl script.
Just so you know ... there is nothing special about the errors - any error of any type that gets reported in perlIS-err.log will stop IIS - missing module, bad syntax, output to STDERR they all bring IIS down.
Most of the errors can be caught in an eval block. For example, we do something like the following:
eval { <your code> <output normal web page> }; if ($@) {
Thanks for this - I am going to replace all the STDError warnings with output to the application log - but what concerns me more are the untrappable errors - like a simple syntax problem.
eval{} will trap fatal errors such as syntax errors - and place them in $@ which you can then write to the logfile. But it won't trap warnings - so you still need a way of dealing with them. Is there some facility that allows you to redirect STDERR with something like 2>application.log ? I don't know if that would help - if it's possible it may just circumvent the problem.
Cheers, Rob
Thanks Rob, I will give this a try and see if it can sideline the problem. We have an alternative rountine for specific application errors which we can use for things we are currently writing to STDERR -- Websites at Work - Websites created to put you in control. _http://www.websitesatwork.com.au/websiteneeds.html_ E: _mailto:info@websitesatwork.com.au_ P: +61 (0)2 6161 9376 F: +61 (0)2 8569 1505 M: +61 (0)412 819 376 -- Websites at Work - Websites created to put you in control. _http://www.websitesatwork.com.au/websiteneeds.html_ E: _mailto:info@websitesatwork.com.au_ P: +61 (0)2 6161 9376 F: +61 (0)2 8569 1505 M: +61 (0)412 819 376 -- Websites at Work - Websites created to put you in control. _http://www.websitesatwork.com.au/websiteneeds.html_ E: _mailto:info@websitesatwork.com.au_ P: +61 (0)2 6161 9376 F: +61 (0)2 8569 1505 M: +61 (0)412 819 376
participants (1)
-
Michelle Davis