如何通过cygrunsrv控制Cygwin服务向SCM报告启动成功的时机？

问题翻译 #

我有十几个基于Cygwin的Windows服务，它们依赖一款在Windows启动时运行的应用（因需与用户交互，未以服务形式运行）。这些服务必须等该应用达到特定状态后才能启动。我编写了名为app-ready的小程序，用来定期检查应用状态，希望将它作为服务供上述服务依赖，确保Windows不会在app-ready服务确认应用就绪前启动那些依赖服务。

常规做法是在等待期间让app-ready服务处于SERVICE_START_PENDING状态，待应用就绪后切换为SERVICE_RUNNING状态，以此通知服务控制管理器（SCM）可以启动依赖服务。但cygrunsrv会在单独线程中执行目标应用，自行处理所有SCM回调和状态报告，app-ready无法介入显式控制服务状态。

请问是否可通过cygrunsrv管理Cygwin服务，从而控制服务何时被报告为SERVICE_RUNNING？

针对你的需求，有几种可行方案来控制cygrunsrv管理的服务何时向SCM报告SERVICE_RUNNING：

方案1：用启动脚本阻塞直到应用就绪 #

cygrunsrv默认会在启动目标进程后立即标记服务为SERVICE_RUNNING，但你可以通过脚本阻塞的方式间接实现依赖控制：

1. 编写bash启动脚本（例如app-ready-wrapper.sh）：

#!/bin/bash
# 循环检测应用状态，直到就绪
while true; do
    # 调用app-ready程序，假设返回0表示应用就绪
    if /path/to/app-ready; then
        break
    fi
    # 每5秒检测一次
    sleep 5
done
# 启动长期运行的占位进程，维持服务运行状态
exec tail -f /dev/null

2. 用cygrunsrv注册服务时指定该脚本作为启动命令：

cygrunsrv -I app-ready -p /bin/bash -a "/path/to/app-ready-wrapper.sh" -d "Application Readiness Check Service"

说明：这种方式下cygrunsrv仍会立即报告SERVICE_RUNNING，但脚本会阻塞到应用就绪后才启动占位进程。若将依赖服务设为Automatic (Delayed Start)，可进一步确保启动时机的合理性。

方案2：修改app-ready调用Windows原生API控制状态 #

Cygwin支持调用Windows服务控制API，你可以修改app-ready直接接管服务状态报告：

• 在app-ready启动后，通过OpenService获取自身服务的句柄（需提前知晓服务名称）。
• 在检测循环中，定期调用SetServiceStatus将服务状态设为SERVICE_START_PENDING，并更新dwWaitHint（例如设为5000毫秒），告知SCM继续等待。
• 检测到应用就绪后，调用SetServiceStatus将状态切换为SERVICE_RUNNING。
  注意：该方式可能与cygrunsrv自身的状态报告逻辑冲突，需测试验证兼容性。

方案3：改用Windows原生服务框架封装app-ready #

如果cygrunsrv的封装限制无法满足需求，最可靠的方式是改用Windows原生服务框架：

• 用C++、C#或Python（借助pywin32库）实现标准Windows服务，在服务的Start回调中执行应用状态检测。
• 检测期间持续向SCM报告SERVICE_START_PENDING，就绪后切换为SERVICE_RUNNING。
• 将Cygwin服务设置为依赖这个原生Windows服务，SCM会严格遵循依赖顺序，确保只有app-ready服务进入运行状态后才启动依赖服务。

方案4：定制修改cygrunsrv源码（进阶） #

若你有Cygwin开发经验，可修改cygrunsrv源码添加自定义逻辑：

• 新增命令行参数（例如--wait-signal），让cygrunsrv启动目标进程后，等待进程发送特定信号（如SIGUSR1）或创建就绪标记文件，再向SCM报告SERVICE_RUNNING。
• 修改app-ready，在检测到应用就绪后，向cygrunsrv进程发送信号或创建标记文件，触发状态更新。
  该方案门槛较高，但能完美适配需求，且无需改动现有Cygwin服务的注册方式。

内容的提问来源于stack exchange，提问作者Irfy