The original problem: shutdown is part of correctness
A market-data collector has more work to finish than closing its sockets. It must stop acquisition, drain pending output, preserve durable state, wait for persistence and retain a truthful terminal result.
The reviewed Linux preparation report identified a lifecycle defect in the earlier runtime: the stop handler stopped only one acquisition path, and its shared process owner could terminate persistence children while they still had work to finish. Porting that behavior to a service manager would not fix the ordering problem. The dedicated Alienware Linux collector is the practical hardware context for this lifecycle work.
Investigation: identify the owner of every child
The ownership audit followed acquisition workers, the persistent writer, compaction and validation processes. It separated service liveness from dataset acceptance. A parent process exiting successfully cannot establish that its descendants completed their work.
The resulting design keeps a foreground owner under systemd and retains children in the same service cgroup. The research consumer remains separate from the factual writer. This is a conceptual responsibility boundary; no machine addresses, access configuration or operational paths are published here.
Implemented change: stop inputs before durable workers
The documented stop path first records interruption, then stops acquisition. Paused output is allowed to drain, while persistence workers remain alive for their existing shutdown sequence. An outer deadline bounds how long shutdown can take.
If the deadline forces termination, the outcome remains a failure. Existing spool, markers and worker state must remain available for explicit recovery. A forced stop must never become a successful dataset simply because the service eventually exited.
- One foreground lifetime owner.
- Ingestion stops before persistence is torn down.
- Child exit status and validation results both matter.
- Recovery preserves the original run identity and evidence.
Verification: state the environment that was tested
The reviewed preparation report records focused software checks for signal handling, descendant cleanup, unexpected exits, restart constraints and failure propagation. It explicitly labels synthetic-process checks and mocked system-manager observations.
That evidence supports the implemented lifecycle contract in its tested environment. It does not establish physical-host cgroup cleanup, power-loss recovery, storage permissions, clock discipline or a successful long collection campaign. Those require separate host evidence.
Remaining limitations and the practical lesson
This note reflects the reviewed preparation snapshot. Physical-host acceptance and later 24-hour or 7-day collection outcomes require their own evidence.
The general lesson is to define a collector’s end condition as carefully as its start condition. Service management should preserve the data-integrity contract through interruption, not replace it with a process-health indicator.
Evidence basis
Based on the private project’s Linux lifecycle preparation report and deployment documentation, plus the approved public project brief. This article is an original, sanitized engineering summary; private source and operational artifacts are not included.