I’m running final tests on, and will soon release, NSSM 2.3. NSSM – the Non-Sucking Service Manager – was originally written as a replacement for the venerable srvany, a tool which allows you to install any application as a Windows NT service.

The new release will fix some bugs and add a new feature which may be of benefit to some users who were trying to use NSSM in a way contrary to its original design. I’m posting here to respond to some criticism of NSSM I’ve read on the internet and to talk a bit about how it’s evolved. A more objective discussion about how the tool works is more appropriate for its homepage, hence my choice of a blog post for this theme.

It’s been a source of pride to me that NSSM has carried on trucking for several years now without any updates. When you see a project which hasn’t had a release in years and years you can either look at it as an abandoned project or a stable one. It’s nice to know that people are still downloading it and finding it useful so long after it was originally written.

This brings me to the criticism I mentioned. I read a piece whose author described what he saw as a "disadvantage" of NSSM, namely its behaviour when the monitored application exits. The author thought that it was a waste of time and symptomatic of a Not-Invented-Here attitude to detect application failure and restart it. He argued that the existing ability of Windows to take service recovery action should be used instead.

This got me thinking. I’m not averse to criticism and I do try not to reinvent wheels so I considered the point carefully. The conclusion I drew was that it’s been so long since NSSM was originally written that people may have forgotten the problem it was designed to solve. That’s not necessarily a bad thing, as it implies that the problem may have gone away. Join me, then, as we walk down memory lane and meet srvany…

Freelancer and srvany

Back in 2003 I was playing Freelancer, an enjoyable space trading/combat game where you flew around fighting off pirates, running trade routes through the galaxy, making money and upgrading your ship. You could play multiplayer over the internet and there was a dedicated server which enabled you to disconnect and reconnect to find your character and ship intact. It only lacked a truly persistent world with thousands of players, rather than five or six to be an awesome MMO. Indeed even now when any space MMO is released nowadays I find myself lamenting how much cooler it would be if the developers had just taken Freelancer and made it bigger instead of building their own game from scratch.

But I digress.

Freelancer was a lot of fun and had a lot going for it. What it didn’t have going for it was its dedicated server stability. That thing would crash and burn and it wasn’t pretty. People wanted to run it as an NT service so their friends could connect to the game without someone having to connect to the server machine and start it up. In those days if you wanted to run a service more or less your only choice was srvany.

All about services

srvany is a tool provided by Microsoft which allows you to take any application and run it as a service. It may be instructive to talk about services. They have a special API and must behave it specific ways. You can’t just whack in any old application and say "you’re a service" – you need to implement particular routines in the source code for your program. srvany does the service manager interaction for you. It implements the necessary functionality to run as a service itself and launches your application in a separate process. So whilst Freelancer doesn’t know how to be a service, srvany does, and it knows how to run Freelancer.

The bad news

The problem with srvany is that it is somewhat unsophisticated. Yes, it knows how to be a service. Yes, it knows how to run your application. But that’s about it. It doesn’t know what to do if your application crashes and, as I already mentioned, Freelancer would indeed crash.

srvany would start up, register itself with the service manager, launch Freelancer and go to sleep. Then Freelancer would crash and srvany would stay asleep. As far as Windows was concerned, everything was fine. srvany was still running which means everything’s good. Except that everything wasn’t good because the thing you actually wanted to run wasn’t running at all.

The evolution of NSSM

This is where NSSM comes in. It’s an abstraction of a tool I wrote called flmonitor which was designed to run Freelancer as a service by doing exactly what srvany did except that if Freelancer died it would start it up again. Remove the hardcoded execution path of Freelancer and throw in a simple GUI to allow the user to choose which program to monitor and you have NSSM, a clean-room reimplementation of srvany which didn’t fall in a heap if the program you servicified happened to crash.

All these years later the criticism is made that it isn’t NSSM’s job to go around restarting services; that should be left to Windows itself. I take the point. In an ideal world NSSM wouldn’t have to restart things. Unless you remember how it was back in 2003, however, you may not realise that saying "Windows will restart my service when it fails" doesn’t help you much if Windows thinks your service hasn’t failed. Not to mention that service recovery actions, though they are not a new thing and were available back then, still need to be manually configured. NSSM solved a real problem and as a nice side effect gave you some useful functionality that you’d otherwise have to go out of your way to get.

Nonetheless the point stands and NSSM 2.3 features the ability to configure what NSSM does when the monitored program exits.

So as not to give an unwanted surprise to people who are used to its original functionality, NSSM’s default behaviour will still be to restart a failed application just like it always did. It can be configured, however, to do one of two other things. First of all it can ignore the failure and carry on running. In this sense it will act exactly like srvany. Useful for nostalgics or for people who want to run a service once at startup. Indeed I’ve received a handful of emails over the years from people trying to use NSSM to run a batch job when their machine boots up, only to find that after the batch script runs NSSM will run it again, spamming the system with batch jobs and eating CPU. If you really want to do this with NSSM you now can.

The other option is for NSSM to tell the service manager that it is stopping when the monitored application exits. This means that you can then configure the service recovery options in Windows and have the operating system restart your service or run a custom script which you could never reliably get to work with srvany.

As an added bonus NSSM will let you configure different actions depending on the exit code of the application it runs. You could do stuff like exit if the job ran successfully or restart it if it failed, for example.

Bug fixes

Finally there are some bug fixes. I’ve fixed a longstanding complaint whereby NSSM’s messages to the event log were prefixed by a blurb from Windows about missing a messages file. Anyone who’s tried to use FormatMessage() and ReportEvent() to interact with the event log knows what a monumental hassle it is to do so correctly. Anyone who hasn’t can take my word for it. In any case I got round to doing The Right Thing and NSSM’s log messages are now less cluttered and more elegant.

Lastly an issue reported to me on these very pages by Joel Reingold has been fixed. Running applications with really really long command lines now works properly.