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?