Fossil Forum

CGI mode pegs CPU on Windows
Login

CGI mode pegs CPU on Windows

CGI mode pegs CPU on Windows

(1) By Warren Young (wyoung) on 2019-08-18 04:02:59

I've just finished the first version of the [IIS + CGI docs][1] but the resulting configuration causes Fossil to launch and peg the CPU at 100% until IIS times out the request and kills `fossil.exe`. (Which is 15 minutes, by default!)

I think this happens because Fossil isn't detecting a single file name argument as a CGI script, thus giving Fossil [the implicit `?cgi?` parameter][2]. 

Simple test case:

```
PS C:\> fossil C:\inetpub\wwwroot\cgi\repo.fslcgi
C:\bin\fossil.exe: unknown command: C:\inetpub\wwwroot\cgi\repo.fslcgi
C:\bin\fossil.exe: use "help" for more information
```

If you give the "`cgi`" parameter explicitly, it does work, although it then gripes about the missing `SCRIPT_NAME` variable. I assume IIS will pass that variable, so that's of no real concern.

Although I make a pretty compelling argument at the top of that new document that you almost certainly should not be using CGI on Windows, it'd be a shame to have gone through all of the effort to write that document only to have it document a configuration you can't actually use.

Has anyone gotten this working before?

I assume it's a fairly easy fix, but I'm not really set up to build Windows executables here, so I'm not the best person to fix this apparent bug in `fossil cgi`.

[1]: http://fossil-scm.org/fossil/doc/server-docs/www/server/windows/cgi.md
[2]: /help/cgi

(2) By Thomas Schnurrenberger (tsbg) on 2019-08-18 09:14:49 in reply to 1 [link]

There is nothing wrong with Fossil and CGI on Windows.

Please see the following link on Microsoft Docs for installing and configuring CGI for IIS: <https://docs.microsoft.com/en-us/iis/configuration/system.webserver/cgi>

On Windows, everything is a little bit more complicated :-(

By the way:

Fossil server/ui works very well on Windows. This should be corrected in the Setup Tutorials matrix of the server document.

(3) By Warren Young (wyoung) on 2019-08-18 09:23:29 in reply to 2 [link]

> There is nothing wrong with Fossil and CGI on Windows.

Have you got it working, then?

I don't believe my problem is with the IIS CGI configuration — aside from the fact that it requires so much manual configuration out of the box — but with Fossil itself.

See my simple test case. That's how my configuration launches `*.fslcgi`.

> Please see the following link on Microsoft Docs

That's a very different path than the one I took. I'd need to know that it solves some real problem with my method before I rewrote my tutorial using that other method.

> Fossil server/ui works very well on Windows.

Are you asking for someone to write `www/server/windows/none.md`? My main objection to that idea is that the closest equivalent of `/etc/rc.d` on Windows is the user's startup items, which doesn't get run until someone logs in, which pushes you toward the `windows/service.md` document for any true "server", as compared to some user's workstation. For a proper server, you want Fossil to start before any user logs in, and to remain running after all users have logged out.

Still, if you want such a document to exist, we're [open to contributions][1]. Now's a fine time to get it in there.

[1]: https://fossil-scm.org/fossil/doc/trunk/www/contribute.wiki

(4) By Thomas Schnurrenberger (tsbg) on 2019-08-18 10:14:08 in reply to 3 [link]

> Have you got it working, then?

Yes, but not on IIS. I use Fossil CGI with Apache for Windows and the CivetWeb embedded server. This is why I say that Fossil CGI works on Windows. I do not use IIS for myself.

> I don't believe my problem is with the IIS CGI configuration

I think this is exactly the problem. According to Microsoft Docs, you need to first install the CGI environment. The CGI environment ist **not** installed by default. The symptoms you describe at the start of the thread, let me assume that Fossil is not running in a proper CGI environment.

> Are you asking for someone to write www/server/windows/none.md?

I think that the current version of this document is useful for Windows users too.
The server terminates when the user logs out, this is a fact that most users will learn quickly and switch to another method.

(5) By Warren Young (wyoung) on 2019-08-19 05:14:47 in reply to 4 [link]

> Yes, but not on IIS. I use Fossil CGI with Apache for Windows

That's a helpful observation. It caused me to go back and re-test, and I now believe it's some combination of a difference in the way IIS launches my `*.fslcgi` scripts and the way Fossil then handles it when launched that way.

First, realize that `fossil.exe` *does* start when you hit this CGI URL. That means CGI is configured and working, at least to some extent.

Second, my earlier diagnosis about `fossil.exe` not getting the implicit `?cgi?` parameter when passed a CGI script name is incorrect. Fossil supplies that verb implicitly when the calling web server passes it the `GATEWAY_INTERFACE` environment variable.

There are also a small number of other required environment variables for Fossil CGI to work: `SCRIPT_NAME`, `PATH_INFO`, and `REQUEST_URI`. 

That then sent me off on a long, fruitless chase for a method to either show or set the necessary variables on IIS. I couldn't even get something so simple as this batch file to work:

```dosbatch
    @echo off
    echo Content-type: text/plain
    echo.
    set
```

Configuring IIS to launch `*.bat` via `cmd.exe` and then hitting that URL results in a "502.2 Bad Gateway" error, claiming I haven't given "a complete set of HTTP headers." But I can't find any documentation that defines "complete!" All my web searching claims that `Content-type` and *maybe* the `HTTP/1.0 200 OK` header suffice. I've tried it both ways.

Without a method for printing the environment variables that IIS passes to CGI processes, I can't tell which of the environment variables which Fossil considers necessary is missing, short of installing a development environment on this IIS VM and then running it under a debugger. That's *way* more work than I want to go to just to complete this article.

I'm throwing in the towel on this for now. Even if I can get it working, it's turning out to be a lot more work than the reverse proxy method, which is more modern and more powerful besides. I can't see any good reason to sink more time into this. If someone else comes up with a fix, I'll happily test and document it, but for now, I'm done.

Meanwhile, if you want to document your Apache + Windows + Fossil method, we'd be willing to [accept the contribution][2].

> you need to first install the CGI environment

I couldn't have gotten very far in constructing my tutorial without having that installed. I just didn't document that step in my tutorial. That documentation oversight is fixed on the `server-docs` branch now.

> I think that the current version of this document is useful for Windows users too. The server terminates when the user logs out, this is a fact that most users will learn quickly and switch to another method.

I've documented this method and its problems [here][1].

[1]: http://fossil-scm.org/fossil/doc/server-docs/www/server/windows/none.md
[2]: https://fossil-scm.org/fossil/doc/trunk/www/contribute.wiki

(6) By Warren Young (wyoung) on 2019-08-19 05:26:56 in reply to 5 [link]

> There are also a small number of other required environment variables for Fossil CGI to work: `SCRIPT_NAME`, `PATH_INFO`, and `REQUEST_URI`.

I should point out that I've verified that my `fossil.exe` binary can start in CGI mode with this batch file:

```dosbatch
@echo off
set GATEWAY_INTERFACE=CGI/1.1
set SCRIPT_NAME=/cgi/repo.fslcgi
set HTTP_HOST=localhost
set PATH_INFO=
set REQUEST_URI=/cgi/repo.fslcgi/doc/trunk/www/index.wiki
fossil repo.fslcgi
```

...where `repo.fslcgi` is a the same Fossil CGI launch script I've been testing my CGI method above with, which points at a clone of the `fossil-scm.org/fossil` repo. I do in fact get the Fossil repo's "home" page when I run this batch file.

All of which brings me right back to my initial question: why does `fossil.exe` peg the CPU at 100% when you run this via IIS instead, until IIS gets tired of waiting for a reply and kills the process?