Alternative method to configure NO_WINDOWS_SERVICE #7350
Comments
|
Tagging as builder since this behavior is dealt with in the builder https://github.com/open-telemetry/opentelemetry-collector/blob/v0.73.0/cmd/builder/internal/builder/templates/main_windows.go.tmpl#L30 |
|
Alternative would be to have different binaries? That will also simplify our build a bit I think. |
|
I like the different binaries option more, more complicated behavior can be built on top of the binaries. This would be a breaking change, so I think we would need a deprecation plan |
|
How would it simplify the build to have different binaries? Would we have a different binary for Windows only to run the collector as service? |
yes, is this common in windows world? |
|
In the Windows world, it seems to be equally as common to run as a service or interactive. You'll need both. |
No. |
**Description:** Fix run as a service detection on Windows. Instead of trying to detect if it is a service or not, for which both `svc.IsAnInteractiveSession()` and `svc.IsWindowsService()` are somehow broken, try to run as a Windows service, if that fails fallback to run as an interactive process. This follows a recommendation of the Windows [service API documentation](https://learn.microsoft.com/en-us/windows/win32/api/winsvc/nf-winsvc-startservicectrldispatchera#return-value). The new code calls `svc.Run` and in case of error checks for `windows.ERROR_FAILED_SERVICE_CONTROLLER_CONNECT`. If this is the error the application can safely assume that it is not running as a service. The duration of a call to `svc.Run` failing with this error was below 3 microseconds in the current GH runner and below 5 microseconds on my box. While this value seems fine for startup I'm keeping the `NO_WINDOWS_SERVICE` option instead of deprecating it (it doesn't seem worth the trouble of deprecating it). **Link to tracking Issue:** Fix #7350 **Testing:** Fix tested on the Splunk fork that deploys the collector as a service and as an interactive process on Windows containers. **Documentation:** Added changelog.
…-telemetry#9042) **Description:** Fix run as a service detection on Windows. Instead of trying to detect if it is a service or not, for which both `svc.IsAnInteractiveSession()` and `svc.IsWindowsService()` are somehow broken, try to run as a Windows service, if that fails fallback to run as an interactive process. This follows a recommendation of the Windows [service API documentation](https://learn.microsoft.com/en-us/windows/win32/api/winsvc/nf-winsvc-startservicectrldispatchera#return-value). The new code calls `svc.Run` and in case of error checks for `windows.ERROR_FAILED_SERVICE_CONTROLLER_CONNECT`. If this is the error the application can safely assume that it is not running as a service. The duration of a call to `svc.Run` failing with this error was below 3 microseconds in the current GH runner and below 5 microseconds on my box. While this value seems fine for startup I'm keeping the `NO_WINDOWS_SERVICE` option instead of deprecating it (it doesn't seem worth the trouble of deprecating it). **Link to tracking Issue:** Fix open-telemetry#7350 **Testing:** Fix tested on the Splunk fork that deploys the collector as a service and as an interactive process on Windows containers. **Documentation:** Added changelog.
Is your feature request related to a problem? Please describe.
The collector uses an environment variable
NO_WINDOWS_SERVICEto regulate its behavior on Windows. By default, the collector will run as a windows service. This environment variable disables the behavior.However, we operate in environments where we cannot set environment variables.
Describe the solution you'd like
We need an alternate way to set this flag, either as command line argument, configuration switch, or other mean.
Describe alternatives you've considered
N/A
Additional context
See signalfx/splunk-otel-collector#2643 for original issue.
The text was updated successfully, but these errors were encountered: