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

Hello, I'm trying to write a perl CGI (under IIS, using perlIS.dll) that spawns a server process when you click a Submit button. This server process does a whole bunch of stuff, fetches code from source control, runs a build, etc. And this perl CGI runs fine when I run it directly from the console, fetches code, runs build etc. But when I call it thru IIS, it seems to fail to successfully spawn the server process.

I've tried using system(), backticks, Win32::Process::Create ... I'm wondering if there is some weird limitation that IIS imposes on processes that prevents them from spawning child processes. Anyone ever heard of this kind of limitation?

If this really is a limitation, it seems I might try to work around it by having the server process always running, and listening on a port for requests, and having the CGI triggering it to run a task through sockets when requested. Though I'd rather not have to build all that if I don't have to.

Replies are listed 'Best First'.
Re: Spawning processes from Microsoft IIS?
by dwm042 (Priest) on Jul 02, 2008 at 17:41 UTC
    If it runs fine on the command line but does not run through a web page, the first thing that comes to mind are permissions issues.
      I think you're right. After some more tracing, it seems my server process actually launches but the first thing it does is make an dbi::ODBC database connection attempt, which fails. So, arg I'm dumb.

      FWIW, the IIS worker processes seem to run under the user "NETWORK SERVICE". I wonder if I just need to get my SQL Server to allow that user to connect/login.

      Can't connect to dbi:ODBC:Profiler: MicrosoftODBC SQL Server DriverShared MemorySSL Security error (SQL-08001) state was 08001 now 01000 MicrosoftODBC SQL Server DriverShared MemoryConnectionOpen (SECDoClientHandshake()). (SQL-01000)

        I am running into this same exact problem but were having issues attempting to set up the connection including NETWORK SERVICES as a user in ODBC Data Sources.