Failing to start on windows

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™ SE Runtime Environment (build 1.8.0_251-b08) Java HotSpot™ 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.<init>(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.

[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 😃