-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it safe to ignore the sessionId on a process to detect it as service? #77350
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
By the way, other interesting output from a host and container :
Container
Maybe instead of a basic "OR" condition, we should identify the session name "services" instead of testing a session ID. |
Tagging subscribers to this area: @dotnet/area-extensions-hosting Issue DetailsHi, On the legacy method WindowsServiceHelpers.IsWindowsService() the logic is based on SessionID == 0 and parent process services.exe. The problem is on a windows container, services.exe has a sessionId = 1 and Golang framework steal the logic from this legacy method. So we experience issues with some Golang softwares hosted in docker and compatibles as cli + service. (Otelcollector, Windows exporter, and any other not launched as host process). Any advice from the Microsoft team ? Original code here : https://github.com/dotnet/extensions/blob/f4066026ca06984b07e90e61a6390ac38152ba93/src/Hosting/WindowsServices/src/WindowsServiceHelpers.cs#L31
|
This is duplicate of #52416 . SessionId is no longer checked in the current Microsoft.Extensions.Hosting.WindowsServices sources: runtime/src/libraries/Microsoft.Extensions.Hosting.WindowsServices/src/WindowsServiceHelpers.cs Line 32 in 36bf84f
|
Awesome! Thanks a lot for your fast answer. I will circle back with the Golang team. |
Hi,
On the legacy method WindowsServiceHelpers.IsWindowsService() the logic is based on SessionID == 0 and parent process services.exe.
Using services.exe seems enough, or in the worst case a OR condition on SessionID 0 or 1, but I guess the session is a safety guard in case of a third party software with an exe named services.exe.
The problem is on a windows container, services.exe has a sessionId = 1 and Golang framework steal the logic from this legacy method. So we experience issues with some Golang softwares hosted in docker and compatibles as cli + service. (Otelcollector, Windows exporter, and any other not launched as host process).
Any advice from the Microsoft team ?
Original code here : https://github.com/dotnet/extensions/blob/f4066026ca06984b07e90e61a6390ac38152ba93/src/Hosting/WindowsServices/src/WindowsServiceHelpers.cs#L31
Some details here : golang/go#56335 (comment)
The text was updated successfully, but these errors were encountered: