Serving as a Standalone Server on Windows

Serving as a Standalone Server on Windows

On Windows, this method works more or less identically to how it’s documented in the generic instructions.

...but only while fossil.exe is actually running, which is the source of much trouble on Windows. This problem has two halves:

No App Startup Without Desktop

The easy methods for starting a program in Windows at system start all require an interactive desktop. There is no easy way to start an arbitrary program on Windows at boot before anyone has logged in. In Unix terms, Windows has no simple equivalent to the /etc/rc.local file.

You can partially get around the first problem by setting your fossil server call up as one of the user’s interactive startup items. Windows 10 has its own idiosyncratic way of doing this, and in older systems you have several alternatives to this. Regardless of the actual mechanism, these will cause the Fossil standalone HTTP server to start on an interactive desktop login only. While you’re sitting at the Windows login screen, the Fossil server is down.

No Simple Background Mode

Windows also lacks a direct equivalent of the Bourne shell’s “&” control operator to run a program in the background, which you can give in Unix’s rc.local file, which is just a normal Bourne shell script.

By “background,” I mean “not attached to any interactive user’s login session.” When the rc.local script exits in Unix, any program it backgrounded stays running. There is no simple and direct equivalent to this mechanism in Windows.

If you set fossil server to run on interactive login, as above, it will shut right back down again when that user logs back out.

With Windows 10, it’s especially problematic because you can no longer make the OS put off updates arbitrarily: your Fossil server will go down every time Windows Update decides it needs to reboot your computer, and then Fossil service will stay down until someone logs back into that machine interactively.

Better Solutions

Because of these problems, we only recommend setting fossil server up on Windows this way when you’re a solo developer or you work in a small office where everyone arrives more or less at the same time each day, and everyone goes home about the same time each day, so that one user can keep the Fossil server up through the working day.

If your needs go at all beyond this, you should expect proper “server” behavior, which you can get on Windows by registering Fossil as a Windows service, which solves the interactive startup and shutdown problems above, at a bit of complexity over the Startup Items method. You may also want to consider putting that service behind an IIS front-end proxy to add additional web serving features.

Return to the top-level Fossil server article.