.Net Core Windows服务未安装在Docker容器中

本文介绍了.Net Core Windows服务未安装在Docker容器中的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我面临一个非常特殊的问题.我有一个核心Windows服务(XYZ)，其安装程序(XYZ.msi)是使用Wix创建的.我正在尝试将此服务安装在容器中.安装该服务，然后Windows尝试将其注册为服务，该服务超时为我提供了以下信息".在系统事件日志中 XYZ服务(XYZ)服务由于以下错误而无法启动:%% 1053等待XYZ服务(XYZ)服务连接时已达到超时(30000毫秒).，然后卸载该服务.

I am facing a very peculiar issue. I have a core windows service (XYZ) whose installer (XYZ.msi) is created using Wix. I am trying to install this service in a container. The service gets installed, then windows tries to register it as a service, the service times out giving me the following "information" in System Eventlogs The XYZ Service (XYZ) service failed to start due to the following error: %%1053 A timeout was reached (30000 milliseconds) while waiting for the XYZ service (XYZ) service to connect., and then the service gets uninstalled which is expected.

进一步，当我检查应用程序事件日志时，我得到了这些

Further when I check the Application event logs I get these

产品:XYZ-错误1920.服务"XYZ"(XYZ)无法启动.验证您是否具有启动系统服务的足够特权.

Windows Installer安装了该产品.产品名称:XYZ.产品版本:0.0.0.0.产品语言:1033.制造商:....安装成功或错误状态:1603.

因此，为了理解这些错误代码，我提到了错误代码1603 和错误1920上的其他几个链接，但是由于它们非常通用，因此这些链接没有用.

So in order to understand these error codes I referred to Error Code 1603 and few other links on Error 1920, but since these are pretty generic, these links were of no use.

同一服务在本地和其他服务器上都可以正常工作.

The same service is working fine locally and on a different server.

XYZ.msi所在的容器内的文件夹具有这些特权

The folder inside the container where XYZ.msi resides has these privileges

Path : Microsoft.PowerShell.Core\FileSystem::C:\app Owner : NT AUTHORITY\SYSTEM Group : NT AUTHORITY\SYSTEM Access : BUILTIN\Administrators Allow FullControl BUILTIN\Administrators Allow 268435456 NT AUTHORITY\SYSTEM Allow FullControl NT AUTHORITY\SYSTEM Allow 268435456 NT AUTHORITY\Authenticated Users Allow Modify, Synchronize NT AUTHORITY\Authenticated Users Allow -536805376 BUILTIN\Users Allow ReadAndExecute, Synchronize BUILTIN\Users Allow -1610612736 Audit : Sddl : O:SYG:SYD:(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)(A;ID;0x1200a9;;;BU)(A;OICIIOID;GXGR;;;BU)

我还假设所有安装都是通过容器内的ContainerAdministrator帐户进行的.

Also I am assuming that all the installation happen with ContainerAdministrator account inside the container.

现在我无法弄清楚问题是什么，如何进一步解决它，如果它有特权问题，我需要设置什么特权.在这方面的任何帮助将不胜感激.谢谢！

Now I am not able to figure out what the problem is, how to troubleshoot it further and if its a privileges issue what privileges do I need to set. Any help in this regard would be appreciated. Thanks !

编辑:dockerFile看起来像这样

The dockerFile looks like this

FROM mcr.microsoft/windows/servercore:ltsc2019-amd64 SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"] WORKDIR /app COPY [".","."] RUN ["powershell.exe", "./install.cmd"]

WiX .wxs代码

WiX .wxs code

<Fragment> <ComponentGroup Id="ServiceComponents" Directory="APPLICATIONFOLDER"> <Component Id="ServiceComponent" Guid="649E5964-126A-4DF5-95CF-CE7C2474E981"> <File Id="xyz.exe" KeyPath="yes" Vital="yes" DiskId="1" Source="..\xyz\bin\$(var.Platform)\$(var.Configuration)\netcoreapp3.1\win-x64\xyz.exe"/> <ServiceInstall Id="ServiceInstaller" Type="ownProcess" Vital="yes" Name="xyz" DisplayName="$(var.ProductName)" Description="$(var.Description)" Start="auto" Account="NT AUTHORITY\LocalService" ErrorControl="normal" Interactive="no"> <ServiceConfig DelayedAutoStart="yes" OnInstall="yes" OnReinstall="yes" /> <util:ServiceConfig FirstFailureActionType="restart" SecondFailureActionType="restart" ThirdFailureActionType="none" ResetPeriodInDays="1" RestartServiceDelayInSeconds="0" /> </ServiceInstall> <ServiceControl Id="ServiceController" Name="xyz" Start="install" Stop="both" Remove="both" Wait="yes" /> </Component> </ComponentGroup> </Fragment>

推荐答案

尽管我仍在调查核心Windows服务的行为，并已启动另一个线程此处以SO社区的观点看来，问题出在服务的实现方式上.这是一个奇怪的行为，但是如果我不使用 core 3附带的Worker模板，而是像使用ServiceBase和IHostingLifetime在 core 2.1中完成的那样创建服务，则它在所有环境中都可以正常工作.

Although I am still investigating the behavior of core windows service and has started another thread here to take the SO community's view on this, it appears that the problem was with the way the service was implemented. It's a strange behavior but if I do not use Worker Template that comes with core 3 and instead create the service like it was done in core 2.1 using ServiceBase and IHostingLifetime it works fine in all the environments.