Add an installer option to not install the service

[jantari]

Hello,

because of the issue with windows_exporter not starting on boot, discussed here:

#551
#637
golang/go#23479

the only reliable way to use this software is to wrap the service in a tool such as WinSW or the classic nssm.

That isn't ideal, but at least it works - however it poses a new problem: Because the windows_exporter MSI always forecfully installs the windows_exporter service my ansible role to deploy the windows_exporter now always has to do two consecutive changes and is not properly idempotent anymore:

After installing or updating windows_exporter (change 1), it has to replace the auto-created, non-functioning service from the installer with the winsw-wrapped version of the service again (change 2 - even though the winsw service and its configuration haven't changed, this task will now result in a change)

This service flip-flopping during a rollout could be avoided if the MSI installer exposed an argument that allows the service-creation to be suppressed during the install.

Thanks!

[breed808]

Right now the only difference between the MSI and EXE options provided by this project are the system service and the firewall rules (plus any intrinsic MSI behaviour).
Is the EXE not an option for your use case?

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[jantari]

I have worked around the issue by giving the working (WinSW-wrapped) service a different name (such as windows_exporter_winsw). Now I only have to delete/disable the windows_exporter service after every update of windows_exporter, but an update is a change anyways so it doesn't matter that we tack on another required follow-up change.

Using the EXE would be very inconvenient for two reasons:

1. We use package managers like chocolatey or winget to provision and update software, and both only carry the MSI installer. To use the EXE installer we would have to create and maintain a custom software package.
2. The EXE download is not an installer, just a "portable" executable. This means it doesn't register its presence on the system with the MSI software database or the registry keys for ARP. This means it won't be tracked by software inventory systems. We have to verify that updates are being installed and are working as expected in case our deployment contains a (logic) error or a bug and an update rollout fails without it being apparent.

Software that's in the MSI database or at least the registry can easily be inventoried and tracked across thousands of systems by external tools.

[breed808]

To confirm, the request originated from a need to manage the windows_exporter service, due to the MSI-provided service failing to start?

Is that still the case now that #1047 (window_exporter >= v0.20.0) has been implemented?

[jantari]

Thanks I will test it again, for a long while I could not use windows_exporter v0.20.0 because the chocolatey package was broken but that has been resolved.

[jantari]

When attempting to test v0.24.0 on some machines I ran into a follow-up problem: #1368

Since I had removed the (formerly unreliable) windows_exporter service intentionally in favor of my own, now, when I perform a reinstall of windows_exporter to recreate the service and remove my own wrapper-service (windows_exporter_winsw) I am left with no windows_exporter running at all - because reinstalling the software did not recreate the missing service.

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[jantari]

To confirm, the request originated from a need to manage the windows_exporter service, due to the MSI-provided service failing to start?

Exactly.

Is that still the case now that #1047 (window_exporter >= v0.20.0) has been implemented?

I checked across our systems where we deployed 0.24.0 without a WinSW wrapper to test it, and we haven't seen these issues with the service failing to start anymore. Thus this issue is resolved for me, thanks.