Context
Task 1.29 implemented daemon management commands (netclaw daemon start|stop|status|install|uninstall). The current implementation is Linux/macOS-focused:
- Graceful stop uses
kill(pid, SIGTERM) via P/Invoke to libc — falls back to Process.Kill() (SIGKILL equivalent) on Windows
- PID file at
~/.netclaw/netclaw.pid — works cross-platform but is not the Windows convention
- Service install/uninstall targets systemd only — prints an error on non-Linux platforms
What needs to change for Windows
Graceful shutdown
- Windows has no SIGTERM. Options:
- Use
GenerateConsoleCtrlEvent (Ctrl+C) if the daemon has a console
- Use a named event/mutex that the daemon listens for
- Use the daemon's
/api/health/ready endpoint pattern — add a /api/shutdown endpoint
Service registration
- Replace systemd unit generation with Windows Service registration
- Options:
sc.exe create, or use Microsoft.Extensions.Hosting.WindowsServices so the daemon can run as both console app and Windows service
- May need a separate
install-service flow since Windows services have different lifecycle semantics
PID file
- PID files work but aren't idiomatic on Windows
- Consider using a named mutex for single-instance enforcement on Windows instead
Scope
This is a follow-up to the daemon+thin-client architecture work. Not blocking MVP (Linux homelab target), but needed before any Windows distribution.
Context
Task 1.29 implemented daemon management commands (
netclaw daemon start|stop|status|install|uninstall). The current implementation is Linux/macOS-focused:kill(pid, SIGTERM)via P/Invoke tolibc— falls back toProcess.Kill()(SIGKILL equivalent) on Windows~/.netclaw/netclaw.pid— works cross-platform but is not the Windows conventionWhat needs to change for Windows
Graceful shutdown
GenerateConsoleCtrlEvent(Ctrl+C) if the daemon has a console/api/health/readyendpoint pattern — add a/api/shutdownendpointService registration
sc.exe create, or useMicrosoft.Extensions.Hosting.WindowsServicesso the daemon can run as both console app and Windows serviceinstall-serviceflow since Windows services have different lifecycle semanticsPID file
Scope
This is a follow-up to the daemon+thin-client architecture work. Not blocking MVP (Linux homelab target), but needed before any Windows distribution.