Worker Supervisor as an OS Service

1. The problem: the worker must not inherit the user-session lifetime

A worker launched by a tray process or interactive shell can disappear on logout, reboot, or crash. Worse, multiple launch paths can create two workers consuming the same queue. This lesson turns “a running process” into an auditable lifecycle owned by the operating-system service manager.

2. Owned boundary: what the supervisor owns and what it does not

The supervisor owns long-lived lifecycle, service identity, startup dependencies, state/log paths, single-instance ownership, bounded recovery, and graceful stop. Lower-privilege job execution belongs to LOC-007 and coordinator protocol belongs to LOC-008; this lesson therefore does not absorb sandbox or RPC-envelope design.

3. Separate desired state from observed state

desired_state=RUNNING is intent, not proof. observed_state can be STARTING, READY, STOPPING, FAILED, or CRASH_LOOP. Without this separation, automatic restart can hide repeated failure behind the appearance of an always-running service.

4. Service identity: dedicated and least-privilege

The service should run under a named, auditable identity rather than an interactive user account or unnecessarily broad authority. Windows SCM starts a service in its configured security context; Linux service configuration similarly needs explicit ownership and runtime permissions. Supervisor identity does not grant the executor arbitrary job authority.

5. Startup dependencies and boot ordering

A service should distinguish required dependencies from preferences. A present network interface does not prove that the coordinator or storage is usable. The ledger records each dependency, its evidence, and the behavior when unavailable; insufficient evidence keeps the service in STARTING or NOT_READY.

6. Process running is not readiness

A live PID proves process existence only. Readiness needs separate evidence such as a local self-check, queue initialization, or application health state. Until that evidence exists, a process may be RUNNING while the service remains NOT_READY for work admission.

7. Watchdog is an explicit signal, not an inference from process existence

With systemd, a watchdog is refreshed by explicit service-manager notification. That produces clear liveness evidence, but a fresh watchdog still does not prove business readiness. MAKNOW therefore records watchdog and readiness as separate columns in the recovery ledger.

8. Restart policy must be bounded, countable, and backed off

Immediate unlimited restart can become a crash storm. The policy records failure count, reset window, backoff, and a retry ceiling. When failures exceed the bound inside the window, the service enters CRASH_LOOP and recovery changes from automatic retry to operator escalation.

9. Single-instance ownership and duplicate start

The service manager should be the sole owner of the supervisor lifecycle. A tray process, task scheduler, or manual script must not create a second worker. Every start path needs an inspectable ownership token or lock; two active instances are an ownership failure even if both appear healthy.

10. Graceful stop, drain, and stop timeout

Stop first closes new intake, drains in-flight work, then records termination. If drain exceeds the bounded timeout, forced termination is recorded with reason and exit evidence. Sending a stop signal alone does not prove the service reached STOPPED.

11. Durable state directory and log sink

Recovery state must not live in an interactive user's temporary session or an ambiguous working directory. State path, log sink, ownership, and retention should be explicit so reboot or logout does not erase evidence. These operational paths must not become a route for exposing job secrets to the supervisor.

12. Linux/systemd: mechanisms are not MAKNOW policy

Restart=, WatchdogSec=, and watchdog notifications are systemd mechanisms. Their configured values do not by themselves define correct MAKNOW policy. MAKNOW uses them to implement a lifecycle while deriving READY and CRASH_LOOP from combined evidence.

13. Windows SCM: service state, account, and failure actions

SCM maintains installed-service state, runs the service under its configured account/security context, and supports failure actions with delay/reset behavior. Those primitives map to the same platform-neutral lifecycle and must not be treated as application-health proof.

14. Lab: Worker Supervisor Service Contract & Recovery Ledger v1

The fixture begins with a tray-launched worker that disappears on logout and later starts twice after a crash. Build the 23-dimension evidence ledger, reject process-only readiness, detect crash loops, reject duplicate ownership, and record stop/drain behavior with a timeout. Expected labels are not exposed in the learner package.

15. Transfer: Linux to Windows without copying directives

Rebuild the same lifecycle on Windows: service manager, service identity, startup evidence, readiness/watchdog equivalent, bounded failure actions, graceful stop, durable paths, and single-instance ownership. The exit criterion is a stable platform-neutral lifecycle with mechanisms adapted to the target service manager.