Failing to start on windows

[alex-tsbk]

Hi. I'm trying to start this on Windows machine and that resulting in failure.

OS: Windows Server 2016 Datacenter

Java: java version "1.8.0_251" Java(TM) SE Runtime Environment (build 1.8.0_251-b08) Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode)

Exception I'm getting: PS C:\java_exporters> java -jar cloudwatch_exporter-0.8.0-jar-with-dependencies.jar 1234 .\us-east-1-ec2-metrics.yml

Exception in thread "main" java.lang.IllegalArgumentException: Unknown signal: HUP at sun.misc.Signal.(Unknown Source) at io.prometheus.cloudwatch.ReloadSignalHandler.start(ReloadSignalHandler.java:12) at io.prometheus.cloudwatch.WebServer.main(WebServer.java:34)

Is it even possible to run this on Windows?

Update

For those folks who land here - this is what you can do:

1. Clone repository locally

2. I've personally used IntelliJ Idea as I'm super unfamiliar with java.

3. Comment out //ReloadSignalHandler.start(collector); in WebServer.java

4. Build the project and make sure there are no issues. IntelliJ Idea should pull all required dependencies for you.

5. In "project structure" go and create new JAR artifact choosing "From module with dependencies" (make sure proposed path to manifest file looks legit)

   Note that for some reason default path for manifest wasn't working properly so I had to store it under a different path: /src/main/resources/META-INF (note: you'll have to create this path before creating artifacts - this way you can select it when selecting main class file)

6. Build -> Build Artifacts -> cloudwatch_exporter -> Build

7. All done. Test it with a simple *.yml file and make sure you're all set.

[brian-brazil]

Hmm, I could see how that mightn't work on Windows. Would you like to send a PR?

[alex-tsbk]

Sure. I'll see what I can do to get this running.

[alex-tsbk]

Update: so the only workaround I found is to stop using ReloadSignalHandler.start(collector); in WebServer class and commenting out ReloadSignalHandler.start method body togather with references to

import sun.misc.Signal;
import sun.misc.SignalHandler;

Then I rebuilt jar on Windows machine using IntelliJ and tried that - worked like a charm - i was able to start the service on my metrics machine host and get all metrics without any issues.

Side findings - it does seem that there is no windows version of sun.misc.Signal and couple threads on stack overflow propose different mechanisms of handling exit codes: https://stackoverflow.com/questions/5023520/sending-signals-to-a-running-jvm.

@brian-brazil I'm not sure if it'll make sense submitting PR which potentially is a breaking change for consumers that depend on that functionality. For now, I'm going to stick with my custom-built version.

[brian-brazil]

I had presumed so, the trick is disabling it just on Windows.

[alex-tsbk]

I've updated the ticket with a workaround. So maybe keep it open for some time to help folks like me who are bound to windows platform.

[matthiasr]

Ideally, we would detect whether HUP is available on the platform and don't use it otherwise. Is there an equivalent mechanism on Windows?

[mindw]

Ideally, we would detect whether HUP is available on the platform and don't use it otherwise. Is there an equivalent mechanism on Windows?

@matthiasr since an http based reload mechanism exists and works well, the Unix signal based seems redundant.

[matthiasr]

Ah cool. I am hesitant to remove it for the platforms it works on but it sounds like we can do without it for Windows.

[matthiasr]

Reading up on signals in Java (signal chaining, more info on sun.misc.Signal) makes me reconsider whether we should support this at all.

Requiring Windows users to recompile is not a solution.

I see multiple ways to solve this:

Keep the current approach but fix the hard dependency on platforms that support HUP

I don't know how to best do this. Is it enough to catch the exception and carry on without the signal handler, or are there other JVMs where sun.misc.Signal is not importable at all?

Deprecate and remove the SIGHUP reload support

This seems to be what the Java ecosystem wants us to do – stop trying to mess with operating system signals that are inherently not portable. A possible deprecation path would be to

1. Emit a clear log line stating that HUP reloads are deprecated and due to being removed whenever one is received (1 version)
2. Put the handler behind a flag, off by default. Update the log line to be even more dire. (1-2 versions)
3. Delete the signal handling code

[mindw]

@matthiasr The second approach get's my vote. IMHO Less is more :)