Tyr_7BE has asked for the wisdom of the Perl Monks concerning the following question:

Hey all

This has been killing me for like half a day now.

I'm taking over admin for a web server (IIS on W2k) and all of a sudden one of our scripts stopped working.

The script is called "debug.cgi". IIS is set up to pass all cgi files to C:\Perl\bin\perl.exe, so for some reason .cgi scripts are passed to perl. It's been working great up until now, when all of a sudden it stopped working.

When you try to run the script by submitting a web form, the following pops up:

"Serious Problem: Invalid argument at C:\website\debug.cgi line 324."

Opening up debug.cgi and going to line 324, I see the following:

open ( WEBLOG, "Y:\\access_log" ) or die "Serious Problem: $!";

This is the only instance of the words "Serious Problem" in the entire script.

Now I wrote a test script that does nothing but open up Y:\access_log and print out the contents, and it works great, so there are no problems with permissions or anything like that. That tells me it might have something to do with the way IIS is handling its perl. Does anyone know anything whether there's anything different that IIS does to handle perl? Perhaps a different username? Has anyone come across anything similar?

Replies are listed 'Best First'.
Re: Perl on IIS
by jfroebe (Parson) on Jan 15, 2005 at 00:06 UTC
    Try:
    open ( WEBLOG, "<", 'Y:\\access_log' ) or die "Serious Problem: $!";

    Jason L. Froebe

    Team Sybase member

    No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

      No deal, I'm afraid :( Still returns the same error.
Re: Perl on IIS
by gellyfish (Monsignor) on Jan 17, 2005 at 15:04 UTC

    It's not clear whether you are running the test program from the console or not. If you are and if Y: is a network drive then this will be the problem - the drive letter will not be mapped for the user that the CGI program runs as - you will need to access the file using the full UNC path, making sure of course that the IUSR_<whatever> has permission to access the network resource.

    /J\

      Problem solved! Thanks all for your help, but it turned out to be a smbd daemon running wild. Killing and restarting smbd and nmbd did the trick. I knew perl scripts didn't break themselves.