Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Win32 Hosting companies not supporting Perl

by cosmicperl (Chaplain)
on Nov 01, 2004 at 21:27 UTC ( #404427=perlquestion: print w/replies, xml ) Need Help??
cosmicperl has asked for the wisdom of the Perl Monks concerning the following question:

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

  • Comment on Win32 Hosting companies not supporting Perl

Replies are listed 'Best First'.
Re: Win32 Hosting companies not supporting Perl
by Elian (Parson) on Nov 01, 2004 at 23:12 UTC
    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.

Re: Perl problem on Win32
by cosmicperl (Chaplain) on Nov 01, 2004 at 22:10 UTC
    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

      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.


        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.
Re: Win32 Hosting companies not supporting Perl
by iburrell (Chaplain) on Nov 02, 2004 at 19:51 UTC
    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.

      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;)

        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.

        Hi jdv79,
           Finally someone with Actual Experience of this problem. Not just another Linux programmer who wan't to scream perl never has any problems. You're experiences are common place for people with windows running Perl. That's why Win32 hosting companies are leaving Perl in droves. This simply can't do. I'm not expecting the world to conform to my ideals (there are some pretty strange people in here), but I am expecting Perl to at least have an option to deal with run away processes.

        Perl.exe -k300 %s %s

        I don't see a single problem with implementing that. How will it effect current perl users? It won't in the slightest! How will it help ALL windows users? VERY VERY MUCH!

        It's the solution I am now persueing. Any pointers would be great, I've never dealt with Perl internals.

      This is not just the ISAPI extention. This is a problem withthe win32 Perl.exe as well.

      Also part of this problem occurs with Apache on Win32, and Apache on Linux. Remove the Alarm() function and run the same Perl script from Apache. When the script is running click STOP or Refresh in your browser.

      Now take a look at your running processes. You'll see that the script is still going. Wait until your timeout setting has passed, take a look at your running processes, and guess what? The script is still running. And it'll keep running until you kill the process yourself.

      Please NO MORE comments from people who have not experienced this problem OR have not bothered to test for this problem with the required code.

        Again NO COMMENTS from anyone who hasn't actually tested for this problem.
        Please NO MORE comments
        Downvoted -- for pretending you can decide who has the right to comment here and who doesn't.
Re: Perl problem on Win32
by TedPride (Priest) on Nov 01, 2004 at 21:54 UTC
    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.
a few clarifications
by cosmicperl (Chaplain) on Nov 02, 2004 at 00:39 UTC
    Ok. Thought I should clarify a few things.

    This isn't a problem I'm having with my hosting company. I have my own dedicated server, which I manage well without trouble.

    I sell commercial CGI scripts.

    In my 5 years experience selling these scripts to customers with every kind of hosting company you can imagine, I have found that a growing number Win32 hosting companies are not installing Perl because of the problems mentioned in my first article.

    Such companies are easy to find, just search for "windows hosting php asp -cgi". Google returns 1,520,000 results.

    This is a number which keeps on growing. In my view Perl has the capability to be the most popular multi platform scripting language in the world. If it weren't for this fixable issue there would be no reason for Win32 hosts not to have Perl.

    Recent polls show that PHP and ASP are now more popular than Perl for internet applications.

    All because of this issue, which has been the same issue for 5 years. Why is the Perl community which I am a part of letting this happen. Why isn't anything being done?????

    I'm now fed up with this problems existance, and I'm taking it upon myself to make sure it is sorted.

    C, or Python, or Scheme, or Fortran, or INTERCAL are not commonly used for internet apps at all. For similar or the same reason.

    I'm not saying Perl should never run for more than a fixed number of seconds. Of course perl scripts should do this. But when perl is launched from Apache or IIS it should have a set timeout. One that can't be broken by the users hitting his stop or refresh button.
      Downvoted due to being Just Plain Wrong.

      What evidence do you have that this is *the* issue preventing people from installing perl on Windows? My experience is in fact that that is a non-issue. What evidence do you have that this same non-issue is the reason that C, Python, Scheme, Fortran and Intercal are not commonly used for "internet apps". Please explain how this does not contradict the fact that major "internet apps" like exim, apache, bind, openssh and INN are all written in C and mailman in Python.

      Fact 1: Apache / *nix is a far more common hosting platform than IIS / Windows

      Fact 2: Perl comes automatically installed on most if not all *nix and *nix-like OSes

      Opinion: It looks to me like you're talking nonsense. You say you sell perl scripts, and that perl scripts running on IIS are running into infinite loops and causing problems. Would these scripts happen to be yours? If so (and this is conjecture - not fact) then the problem would not seem to be perl or IIS.

        This is the reason why the problem isn't being resolved. Ignorance and denial in the Perl community

        "Downvoted due to being Just Plain Wrong." - Likewise.
        "What evidence do you have that this is *the* issue preventing people from installing perl on Windows?" - 5 years experience talking to many different windows hosts about why they won't install Perl.
        Feel free to contact them yourself. Meeting many people and E-business networking events and being asked about why Perl is such a problem on Win32. To these people this is a big deal, and why they do not choose Perl. Business people not choosing Perl is a problem.
        "internet apps" - As in website applications. Scripts. Bind, Apache are obviously done in C. But last time I looked Apache wasn't a script that ran on apache - get the drift? Same goes for Bind, etc. What percentage of CGI Scripts are coded in C & Python put together? I'll give you a clue <1%

        quote - "Fact 1: Apache / *nix is a far more common hosting platform than IIS / Windows
        Fact 2: Perl comes automatically installed on most if not all *nix and *nix-like OSes"
        Trees are also green and the sky is blue. This is irrelevent to the issue.
        No MY scripts are not running into infinate loops on IIS. I heavily test all my scripts and include failsafes on all routines that might possibly cause an infinite loop if errourness data is input.
        YES there are hundreds a new Perl programmers
        YES their scripts will create infinate loops while they are still learning and debugging.
        YES there are thousands of Perl scripts avilable to download and install
        YES many of this scripst will have bugs
        YES some of them will generate infinate loops
        YES this will cause the outlined problems with Perl on Win32
        NO I'm not saying this isn't an error in their perl scripts causing the infinite loops
        NO this doesn't stop the fact that it's happening, and that it will continue to happen until some failsafe is put in place.

        Here is some sample code for those of you that want to see this error in action. It's purposefully designed to create the problem

        alarm 30; $|=1; ## Choose operating system BEGIN { if (($^O eq 'MSWin32') || defined($ENV{'OS'})) { $operatingsystem = 0; $operatingsystemoldnt = 0; $systempath = "$ENV{'PATH_TRANSLATED'}"; $systempath =~ s/(\\[a-z0-9]*\.pl)$//g; unless ($systempath) { $systempath = "$ENV{'SCRIPT_FILENAME'}"; $systempath =~ s/(\/[a-z0-9]*\.pl)$//g; } ## End unless # $operatingsystemoldnt = 1; # $slash = '\\'; $slash = '/'; } ## End if else { $operatingsystem = 1; $systempath = "$ENV{'SCRIPT_FILENAME'}"; $systempath =~ s/(\/[a-z0-9]*\.pl)$//g; if ($systempath =~ /cgiwrap/) { $systempath = "$ENV{'PATH_TRANSLATED'}"; $systempath =~ s/(\/[a-z0-9]*\.pl)$//g; } ## End if $slash = '/'; } ## End else ## $systempath = "systempath to your folder"; ## Enter the correct val +ue and un-comment this if you are having system path detection proble +ms push (@INC, "$systempath"); } ## End BEGI print "Content-type:text/html\n\n"; ## Directory navigator $directorypath = "c:/"; my @directories; my @variables; my $directoryname = 1; push (@directories,"$directorypath"); until ($directoryname eq "rerasfsdfsdfsdf") { $directoryname = shift (@directories); chomp($directoryname); opendir(CURRENTDIR, "$directoryname"); @dirfiles = readdir (CURRENTDIR); closedir(CURRENTDIR); foreach $filename (@dirfiles) { chomp($filename); unless ($filename eq "." || $filename eq "..") { if (-d "$directoryname/$filename") { push (@directories,"$directoryname/$filename"); print "$directoryname/$filename\n"; } ## End if } ## End unless } ## End loop } ## End loop
        Save and run the script in your browser from IIS, not form the command prompt. Then when it's eating up your CPU quickly open task manager and try to end the process. You'll see that it won't let you (on win2000 at least). The app should die after 30 seconds from the Alarm() setting at the top. Now if you want to see it take down IIS, remove the Alarm() code, run from your browser and click the stop button. Viola IIS is crippled, this is where most WinDose hosts will reach for the reset switch. And heres the best bit, when the machine reboots and is available again the happless user, wondering what the problem is hit's the refresh button and viola, IIS is crippled. After several reboots and very pissed off WinDose hosting company understandable says "I don't get this problem with ASP or PHP, I'm going to remove Perl, it's not worth the effort."

        If you can't admit this problem then your either ignoreant, or plain stupid.

        Is this a problem with the Perl interpreter? Not really, but Perl is the mechanism which allows this problem to exist, and so is responsible for providing the win32 community with a failsafe solution. When the administrator opens up Task manager to see which programs have gone mad, and are taking down the machine, they don't see "Stupid newbie script error", or "badly made script" what the see is "PERL.EXE". So what program do you think they blame?
        To give a little more evidence. This problem used to exist for PHP as well, take a look at this post:-

        Rather than ignoreing this issue, blaming new or bad programmers (as if advanced programmers don't make mistakes from time to time), etc. The PHP people did something about it back in version 3. Take a look at the responces, such as:-

        If I wasn't such an avid perl fan I might be tempted to php, but no way.

        When someone uploads a script that causes an Iloop on my server I run 'top' and kill it. If it's the middle of the night my server will be running like a slug until i wake up and kill the run away scripts. I'd rather not have to do this. It's no where near the problem you get on Win32, but it's still an issue. However on Linux you could argue this is a issue with apache not killing the cgi process it started when the browser stop button is pressed. Should my next stop be apache? Either way, the simplest solution would be perl having some sort of safeguard to prevent this.
      I'm not saying Perl should never run for more than a fixed number of seconds. Of course perl scripts should do this. But when perl is launched from Apache or IIS it should have a set timeout. One that can't be broken by the users hitting his stop or refresh button.
      You're looking for a solution in the wrong place. If a webserver starts a process, it is the webserver's responsibility to kill it. Implementing a timeout like that in perl is trivial but it is the wrong solution and you're simply not going to convince anyone with this trite hogwash. Pretend you're ActiveState and distribute your own version of perl which implements this.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://404427]
Approved by atcroft
Front-paged by diotalevi
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2018-05-23 09:38 GMT
Find Nodes?
    Voting Booth?