How To Run A JAR As A Windows Service With NSSM

Nov 26, 2019 · 4 min read

Ready to deploy your project to production but it’s a JAR file? But it’s a JAR file. Let me show you how to get it running as a Windows Service.

You can download NSSM, the Non Sucking Service Manager from here. While not necessary, you can add either the 32-bit or 64-bit exe to your PATH for convenience.

Package your Java Project as a JAR by your preferred means. My projects use maven, a java dependency manager, so I can just run “mvn package” from my command line. Otherwise, you can use whatever IDE you use’s integrated tools to package the project as a JAR. Now we can begin with NSSM. There are two ways to use NSSM, a GUI or a CLI. I’ll list the GUI way and include the equivalent commands at each step.

Using NSSM To Run A Jar as A Windows Service

Open an elevated Powershell window. Elevated is important as NSSM needs elevated rights in order to install the service.

1. run “nssm install.” This will open the Service Installer

2. The Path parameter is where the path to you java.exe will go. It might vary on your setup, but it typically will be “C:\Program Files\Java\\bin\java.exe”

You can change the application used here by using the set command here.

nssm set SERVICE_NAME Application

3. The Startup Directory needs to be changed. It should point to the target folder that was created when you packaged your project into a JAR.

CLI equivalent is: nssm set SERVICE_NAME AppDirectory

4. Next are the arguments. If you’ve ever started a JAR via a CLI, then this is exactly the same. Your VM Arguments (the -D things) go first, then -jar, and then the path to your newly created JAR file.

So if we had a VM Argument for a number, called -Dour_Number, we’ll want to set it as -Dour_Number=24. Followed by -jar and our JAR file. The path to your JAR file must have quotes. I’m not really sure why, but at least on NSSM version 2.24, it needs them.

I’m not using a quote here for the CLI because I feel it’s more important to note how to do this properly.

The command itself is: nssm set SERVICE_NAME AppParameters

If you do this via a CLI, if an argument contains a path, whether it contains spaces or not, it must be surrounded by quotes. For some god forsaken reason, NSSM removes the quotes put anywhere around any of these input fields. For Path and Startup Directory, this doesn’t seem to matter, but for the arguments, it absolutely does. So, in order to use the CLI to input these Arguments we do it like this:

That’s 3 quotes on each side. Yeah it’s weird. The NSSM doesn’t seem to state this anywhere, so it took me a few days to figure it out. (If you wanted to automate this with a Powershell script like I eventually did, it’s like this):

If it’s an Argument, then: -Dpath_with_space=”\””””$path_with_space\””” (even more quotes).

If it’s just your path to the JAR. You can do it normally like above, “\””quote\”””.

5. Last but not least is the service name. Simple enough, just name it.

CLI equivalent is: nssm install SERVICE_NAME

This will still launch the GUI because it lacks the other parameters needed.

Do it all in one command

So what if you wanted to everything we did above in one fell swoop (well two), it would look like this:

nssm install TestService C:\Program Files\Java\jdk1.8.0_221\bin\java.exe -Dour_Number=24 -jar “\”“C:\Users\Passarelli\Desktop\Test Project\outJar-with-dependencies.jar\”””

Now set the AppDirectory to our target folder

nssm set TestService AppDirectory “C:\Users\Passarelli\Desktop\Test Project\target”

After doing either option, you can now see your service in Services.msc and can start/stop/resume as needed!

You can remove the service whenever you need to by stopping it and then running:

Jar file as Windows service (+bonus jar to exe)

Aug 22, 2019 · 11 min read

So, your project has lived up to production and you’d like to start it with the OS and you don’t manually rise it every time. But how do we do that with a regular jar-file?

There are a bunch of options:

I) Put the bat-file with java –jar launch or exe-file in Windows startup (after making an exe file from jar).

This will solve the problem, but your a p p will start in the best case only with the first login of any user (if you throw bat into startup for all users). But, as you know, a good admin doesn’t walk on the server.

II) Make the Windows task, starting the bat-file at system startup.

This option perfectly solves startup problem, but the manipulation with the app ends here, neither start-stop at any time, nor restart due to errors.

III) Run jar as win service with sc.exe (there is still Srvinstw.exe — GUI version, but we are true-programmers and must use the command-line).

This is a little program from the Resource Kit for creating services from exe-files.

But we have a jar-file, right?! No problem! There are options to try:

1) Run java.exe -jar with parameters directly.

2) make exe-file from jar and turn it into a service.

a) run java.exe –jar from it

b) write bat-file with launch java -jar and run it from srvany.

IV) Use third-party software.

Let’s rake this pile of options, skipping the first two as the least interesting.

0) Application

First, we’ll write a small application with blackjack and resources, depending on passed parameters, in order to feel maximum pain in the agony of trying to make it work as a service.

— swear that there are no parameters

— read certain setting files depending on the passed parameters

— parse these settings by an external library

— pour the same settings in the log every 5 seconds

An app example can be found here:

My result will be the executable jar-file, with dependent libraries and resources outside in the separate folder. You can do whatever you want, experiment.

1) Start the service with sc.exe

Well, to read sc help, just enter:

The result will be «Error. Unidentified command» and further help on possible commands.

A) Create the service with java.exe –jar

I have a jdk dragging around the app, not to depend on versions in the servers and to give my program solidity of a large size. The full path to java.exe is not necessary if it’s in the environment variables. It’s worth noting one annoying and unobtrusive peculiarity: « binPath= » — after any parameter (here is a binPath) immediately comes the equal sign, and then between it and the parameter value a space is required.

Great, the service is created, run it! Oops.

( My TestService will have different numbers in the examples, because the service wasn’t always deleted immediately, sometimes it was just marked for deletion)

Just in case, let’s look if the app log has appeared. But it has! Only a tiny one, containing info from the moment of trying to start the service up until the moment of issuing the error. What happened? Here’s what:

— service started launching java.exe with the required parameters

— our app started its work

— Windows service manager waited some time for a response from java.exe about it successful (or not) launch

— but java.exe returned nothing, because it owes nothing to anyone

— service manager counted down the timeout in seconds and shot off java

Conclusion: not every exe-file is equally useful to run as a service. One does not simply run any exe-file as a service, it must be specially sharpened for Windows service (at least return some data about it launch).

Or maybe try javaw? Try it, but double-V in the name doesn’t mean double victory.

B) Create the service with cmd /c java.exe -jar

What if you run cmd in cmd in cmd and in it run java? Will the whole chain close? Let’s start small — run only java from the cmd, and specify cmd as binpath at service start:

Likewise, it falls off after the timeout. But only the cmd process ends its worthless life, and our mega java app continues to breathe and delight.

It works? Yes! As a full service? No toothing way!

But put our jar-file in a folder with spaces to (“escape”) enjoy the creation of inclined sticks next to quotes a little more:

Look at the registry:

Doesn’t look bad, just parameters should be crammed in quotation marks for complete happiness.

Conclusion: tricks are good, but not always 100% useful.

C) Create the service with srvany.exe java.exe –jar

srvany.exe is also a program tool from the Resource Kit. Its work is simple — run the specified app. I.e. we register srvany.exe as a service with parameters indicating the path to our program. Order: start the service → run srvany → run our app.

Add parameters to launch srvany:

Starting.. watching.. waiting.. watching.. it works!! It’s all? This is the end? Or is something missing? Why invented third-party software (except of self-education and advertising purposes)? You can try to kill the process or invoke the exception in the app. And we will smoothly proceed to the next point.

Conclusion: srvany works, but catching errors is lame.

2) Start the service with third-party software NSSM.

Here is a short list of different software:

— jsvc (pervert’s version: « It can run on Win32 via the Cygwin emulation layer» (с))

We’ll use the last one. For lazy readers repeat the question: why do we need a third-party software? For them, the answer is right from the nssm site:

«srvany and other service helper programs suck because they don’t handle failure of the application running as a service. If you use such a program you may see a service listed as started when in fact the application has died. nssm monitors the running service and will restart it if it dies.»

How does it work? All the same: nssm.exe installing as a service with specified parameters, when the service starts — nssm.exe itself starts, which in turn launches java.exe –jar. Here is a clear run in the task manager for you:

Now in order. Execute « nssm.exe install TestServ » to start the GUI.

We can do the same using the command line:

it’s important for us to indicate AppDirectory, because the configs and libs used by us lie there, next to our app in the resources and res subfolders.

If you are tired of the service or you screwed up when creating it, then run the command:

Let’s look back-to-back at the registry entries:

All parameters and quotation marks are in place. Look at the service info:

Run service.. Hurray! Everything works, logs are written!

Try to kill java or crash your application from the inside.

Conclusion: not written by our magnificent hands, brains and legs third-party software also has the right to life.

3) Automate it!

It’s worthless to start services on 30 servers by handles, the script is necessary! Omit spreading on machines, at least let’s create a service to correctly run the configuration designated on current server just with one variable name change.

But the script is easy! Sure? And if you add spaces in the names? The pain is hiding in details of fine-tuning quotation marks and their escaping. Suppose we put AppDir into a variable. How should we write it in the params and as the current directory? Where are the quotation marks necessary and where not?

use in parameters:

as the current directory:

If configured incorrectly, you can get such an error when starting the service:

Go to system event log for details:

See what’s wrong with registry paths:

Based on the results we draw conclusions about superfluous/missing quotes or slashes in the right places.

The result script looks like this:

And in the params in the registry:

Let’s test restarting. Run app with throwing an exception in a parallel thread, that the app terminates itself after two iterations.

Watch log files, see their re-creation, which means the service restarts our app upon completion. Great! Even logs are presented in the System Event Journal with a source nssm:

Service TestServ ran for less than 1500 milliseconds. Restart will be delayed by 2000 milliseconds.

Conclusion: Automate everything you need, not everything you can, otherwise it may take more time for useless work.

4) Bonus: jar to exe

Now let’s try to convert/wrap/shove our jar-file into exe-file and run it as a service.

Here is a couple of variants:

I haven’t tried it yet, there are a lot of opportunities there, but it’s a bit confusing for our purposes now.

C) Launch4j — standalone program or as a maven plugin.

Use standalone launch4j.

Fill the GUI form and specify path to jar and its params, try to embed JDK inside:

However, it can’t be started, the “start” button is unhighlighted. What’s wrong? Try to save the settings and run it from the cmd:

Oh yea, it’s not visible on the screenshot, but I played around firstly and indicated the jre max version as 9, but it needs to be 11. Erase jre version, run, get:

Erm.. add to the Boundled JRE Path — «\javaw.exe». Doesn’t work. Erase javaw and bin folder. Voila! But wait, now run the exe-file:

Aaarrrgh.. it must be a fat jar.. Okay, move the resources folder. Launch.. Yeah it works!

It can be seen from the running processes that in our case mainTut.exe — is just a wrapper, that launches java-exe –jar with params. Moreover, in the “path to jar” argument is mainTut.exe itself! Let’s try to open our exe-file with the archiver:

Actually, here lies the same thing as in our jar-file.

One point — we allegedly have a built-in JRE, although it’s not noticeable by size and the archive inside. Let’s try to rename jdk folder for verification. That is, it doesn’t work. We’ll not be tormented with all the relations, the main thing — here is a working variant and it’s necessary to test it as a service.

but the result is disappointing, like from the cmd — mainTut.exe closes, but java.exe remains. + somehow it’s necessary to throw different arguments to a jar, cause they are sewn into exe-file.

Conclusion: the simple wrapping of your jar-file in exe will not give you any profit to run it as a service. And no profit at all. The wrapping makes sense rather for assembling an installation package.

General conclusion.

Use NSSM to launch jar-file as a service and enjoy the uptime!

Feel free to shake hand on Medium or Telegram or Twitter.