Win32 Hosting companies not supporting Perl

[cosmicperl]

Hi All,
   I hope this is in the right place, I wasn't sure where to post.

I develop commercial perl software applications. From time to time I get a customer who's Windows host doesn't support Perl. Many times I find that these hosts once supported Perl, but have since removed it after problem. Seeing PHP take onto windows servers where there isn't Perl I got a bit fed up that still nothing has been done about this so I contacted ActivePerl with the email below:-

Hi, I'm a big Perl support, I earn a living producing Perl script for Windows and Unix. It really bugs me when a windows server doesn't have ActivePerl installed. From my experience there are only a couple of things that are preventing all hosting companies form installing ActivePerl.

1) Script errors. Even the best coded scripts will have problems from time to time. Bugs are inevitable. If your bug turns out to be an infinite loop, then you are in big trouble. ActivePerl will eat up all the CPU in seconds and render the IIS server unreachable. If the user then clicks stop on his browser the process will not be killed by IIS after the cgi timeout. If the cgi timeout does kick in this is a whole 5 mins later. By now the hosting company has usually received a complaint from their customers, and the user has clicked refresh a few times so you have lots of scripts going out of control. If the system admin opens task manager they cannot kill any of these perl processes. This all usually resorts in a reboot. 2) This problem exists when running apache on windows as well.


Please, please, please, please, please, please, please Add a update to ActivePerl so that it kills runaway perl processes itself after a configurable amount of time, and limit the amount of CPU it can chew up, so while the process is still out of control before it is killed it doesn't render the server unusable. PHP added this back in version 3.x and this is the one and only reason why you find PHP on more windows machines than Perl these days. Please, please, please add this feature, for every hosting company and perl developer everywhere. Without this feature Perl will never be as popular on Windows machines as it should be.


Please, I'll even write the code to do it myself, just give me the source.

Your response would be VERY much appreciated.

I knew the "Please, I'll even write the code to do it myself, just give me the source." comment was a mistake the moment I sent it, Perl is open source.

They told me it wasn't up to them. I'm still trying to get them to associate .cgi extentions on Win32 to perl by default, as nothing else on Win32 is using them, and new hosts get confused when they have to edit anything in IIS

What should I (we) do. This issue needs to be resolved.

Looking forward to construcive responce.

ATTENTION I appoligise in advance to new readers for the stressed tone in some of my posts. Perl is my passion, and I'm very passionate about perl. I'm easily fired up if I think people are damaging Perl in any way. Please read all my comments before you make a post that may reignite something I've already covered.

2004-11-06 Edited by Arunbear: Changed title from 'Hosting companies not supporting Perl', as per Monastery guidelines

[Elian]

It's important to note that this is not a perl problem, any more than the fact that your CGI programs written in C, or Python, or Scheme, or Fortran, or INTERCAL don't time out. It is well and truly a server management issue, and if your webserver (or whatever server software, or OS, it is) doesn't support time quotas on processes then you have issues very much apart from any capabilities of perl. From your description, I fully expect you're screwed no matter what you do, since your hosting provider looks clueless.

Having said that, Parrot will allow time, memory, and IO quotas, with privilege based overrides, on individual interpreters. Assuming whatever firing off parrot sets those quotas. They certainly won't be on by default, as that's very much the wrong default, but it will be settable.

This probably won't help you, given the issue as described (since if your service provider's not even putting generic timeouts on spawned child CGI processes I expect there's little to no chance they'd configure things right), but the option will certainly be available.

[cosmicperl]

This isn't really one for me. Yes I would benefit, as woud everyone who makes cgi scripts that run on Win32.

The solution would seem unbelievably simple.

Have a new windows environment variable - PerlTimeout. Set this to something like 60. By default Perl.exe launches all perl scripts with the Alarm function set to the PerlTimeout value. If a sript needs longer then the programmer can be careful and use Alarm again to a new number.
Newbies are always going to go straight into program loops without looking up Alarm first. I haven't seem a guide yet that tell you to use Alarm from the start. The functionality to fix this problem has been in Perl from the start, they just need to implement by default.

The last reply I got from ActiveState was this:-
Hi Lyle,
I'm saying that you should feel free to contribute to the Perl project, and that is the strength of an open source solution like Perl, that if someone such as yourself has a specific problem they need solved they are empowered to do something about it.

Please consider ActiveState's role in this equation, however. We provide a free Perl distribution as well as technical support for installation and configuration issues. While we do take many ActivePerl bug reports and forward them on to P5P, as a Perl user you are always going to have more traction reporting serious defects in Perl by using perlbug and engaging in the community process.

best regards,
Jeff Griffiths, Technical Support ActiveState, a division of Sophos http://www.activestate.com

[gellyfish]

I totally agree with the response from ActiveState: there is nothing stopping you making a patch that implements this and sending it to p5p - this is likely to be far more productive than moaning about it here. I also think that asserting that you make money from selling applications written in Perl and then essentially demanding that someone do something for free to help you make more money is at best tasteless.

As to your original suggestion I personally find it entirely without merit, firstly it assumes that all Perl programs are run under the CGI and need only to run for a short time, this is patently untrue. Secondly what you are describing is not a bug in Perl, but a failure on the part of the server administrators combined with the differences between Windows and Unix. IIS has configuration for Processor Throttling (a limit on the amount of time a process can take on the processor) and Script Timeout - it is the responsibility of the administrator to ensure that these are set appropriately for the kind of use that the server will be put to. It might also be noted that the alarm() function is not implemented on Windows, so this would also need to be remedied before implementing your suggestion (Okay, I discover that it is implemented with 5.8.4.) I would suggest that, if the IIS configuration is not sufficient to your needs, you (or the server administrator) should create a small wrapper program that can control the execution of the CGI program.

/J\

[cosmicperl]

The fact that for certain infinite loops, such as the one created from the same script I've given in a commented post below, prevent you from ending the process (this only occurs on Win32, the same script under Linux can be killed), I hold ActiveState responcible. I assume (correct me if I'm wrong) that this would be something to do with the compilation on WinDose. Yes it's probably to do with some stupid way windose handles processes, but again that doesn't stop the problem from existing and a work around being required.

If trying to get more Win32 hosting companies to install perl is a crime then I'm guity as charged. If trying to increase perls popularity is a crime then I'm guilty as charged. If listening to the only reason why more win32 hosting companies haven't installed Perl, and opening a discussion on it to find out what steps I need to take to get the problem resolved is a crime then I'm guilty as charged. If you don't think that this is good merit then what would you prefer? Me to start a campaign to stop people from using perl?
The bottom line is that if more win32 hosting companies are supporting perl then the whole perl community and Perl itself will benefit. The language can retake it's well deserved place as the internets most popular cgi scripting language.

"firstly it assumes that all Perl programs are run under the CGI and need only to run for a short time" - Please point out EXACTLY where ANY of my statements make this assumption. I don't take kindly to people putting plain stupid words in my mouth that I never said, so that they can try to have a pop. I spend my whole day working with perl, it's my livelyhood, not a hobby. And your tell me that some perl operations are not short, and not CGI. Really, no s**t, do you want a medal?
"Secondly what you are describing is not a bug in Perl" - Now if you look all of my comments, you'll clearly see that I AT NO POINT state that this is a BUG in Perl. I say that this is a PROBLEM when perl is running CGI scripts.
"failure on the part of the server administrators" So what are you saying. A administrator with more than 200 accounts on his server should manually vet, test and approve all CGI scripts that get uploaded to the server by a user? Plain ridiculous.
"and Script Timeout" Useful if the user doesn't hit his browsers stop button for the full default 5 minutes. Otherwise this will not kill the process. Same goes for apache on Win32 and Linux.
"you should create a small wrapper program" Finally a good point. Yes I've already been asking ActiveState about the possibility for creating this. My searches on google didn't return any methods. I get the feeling the wrapper would need to be in C++ where I don't have much experience. Then you've got the problem of informing every Win32 host about the wrapper, unless I could convince ActiveState to include it with their release.

Perl knows when it's being calls from a web server be it apache or IIS, the timeout would only need apply in this case. Seemed to obvious to post, but I guess some people need to be told.

[iburrell]

This has nothing to do with Perl the interpreter. Adding a new option to the Perl interpreter would not help. This is purely an issue with the Perl ISAPI extension and IIS on Windows. Unfortunately, the Perl ISAPI extension from ActiveState is not open source and does not seem to be actively maintained. There are other aggravating issues I used to run into. I never had problems from infinite loops.

If Perl ISAPI doesn't work, there are two options for Windows web hosts. One was PerlEx sold by ActiveState. It seems this is discontinued and PerlASPX is replacing it. Two is run Apache and mod_perl or CGI Perl apps. Apache2 on Windows works fine and mod_perl has improved greatly.

If you are going to ask ActiveState to open source the Perl ISAPI extension, I would suggest asking politely.

[jdv79]

If you've never, ever caused an infinite loop then I guess your better than the rest of us.

Its inevitable that malformed scripts will be created and run. The only way to deal with them is to handle them, not dismiss the problem as being programmer error. It is a real problem and its not going to just disappear.

I work for a manufacturing company in NJ who is building a custom web-based ERP/Intranet system. Let me just premise this with saying that they are a 100% m$ shop. When I came onboard they were using VB and I told them that I could do much better using Perl.

So we got Perl running on IIS using the ISAPI extension and all was well until I uploaded a script that brought the IIS server to its knees in seconds. It was then that I learned the following:

* alarm() was not supported
* CPU throttling was not supported

I talked to Activestate about the throttling issue and they said they had no plans to implement anything.

Even if alarm() was supported, which it may by now, this sort of resource management should be done at the server level and not be the responsibility of the programmer. Just as it is done with PHP.

So, basically, everytime that I had a runaway script I had to get a hold of the sysadmin and have him restart IIS. Obviously this casts a rather large shadow of doubt about the usability of Perl in this manner since the entire box could be shut down by a single malfunctioning Perl script. While this is a smaller problem for an inhouse server where things can be controlled to a degree, it is a _HUGE_ problem for a hosting provider.

This also means that everytime an intensive script of mine runs, IIS chews through CPU and memory like it was air and water. The sysadmin was really not happy about this because the "microsoft approved" languages like VB and C# can be throttled and limitted IN IIS.

The outcome from all of this is that they are migrating their entire opertaion to C# and .NET. While their decision of moving to C# and .NET was not solely based on the inadequacies of the Perl ISAPI extension, it was a _very_ signifigant contributor.

If the ISAPI Perl extension had been able to throttle the CPU and maybe even have memory limits and process timeouts I could still have a job doing what I love. Albeit in an environtment that I loathe but, hey, you can't have everything;)

[Anonymous Monk]

The perl community and ActiveState are not one and the same. ActiveState is a for profit company. Sure they're involved in perl development but the problem is and has always been with IIS and the ISAPI extension none of which the open source perl community has any control of.

The solution cosmicperl is proposing makes no sense for perl, and as for ActivePerl, its under ActiveState's control which is under no obligation to listen to cosmicperl. cosmicperl is free as he has always been to do what ActiveState does which is create his own binary distribution of perl for windows. Its incredibly easy, but NOOO, all companies must conform to what cosmicperl believes.

[TedPride]

The easiest solution for a lot of hosting accounts is to get them to move to a Unix server. I've done this before. Another option is to learn basic PHP, which will take you probably about two days. Beyond that, you're screwed. Just pray that ActivePerl gets upgraded to a more helpful version.