An update became a collection failure

I wanted the dedicated Linux host to collect market data without routine workstation interruptions. On 21 October 2026, an unattended Ubuntu update interrupted an active campaign instead. The package-maintenance path invoked needrestart, which can restart services after their software dependencies change.

The incident record showed restart requests for Factory acquisition services. The restarted campaign then refused to continue the interrupted acquisition. That refusal was correct: starting a process again could not turn the missing interval into a continuous recording. I needed to fix the maintenance interaction without weakening that safety contract.

Following the restart beyond the application

The investigation connected the package-maintenance activity to the service restarts and checked what remained running. MCE, the separate Market Context Engine application, was still active in the reviewed incident record. This was not evidence that every service on the host had failed.

Historical certification evidence was retained. A failed or uncertified run stayed failed or uncertified, even where explicit recovery could finish permitted work on already captured data. Restarting acquisition was not allowed to erase the original interruption or extend its deadline.

A finite window for collection

The maintenance policy introduced bounded protection around registered acquisition and final-review windows. During a protected window, package installation is deferred and needrestart defers service and container restarts, including dependencies that could indirectly interrupt collection. The system does not permanently disable maintenance outside protected collection windows.

I did not want protection to become a permanent excuse to leave the host unpatched. The policy has finite service limits and fallback deadlines. Normal maintenance becomes eligible again after all protected windows end. An emergency exception is short-lived and requires the interruption to be acknowledged.

Capture admission also checks that the installed helper matches the approved release and that protection covers acquisition plus shutdown. A missing, mismatched or insufficient policy blocks a new managed capture. The helper itself does not start or stop acquisition.

A separate compatibility problem

Later, Factory and MCE shared a maintenance entrypoint whose installed implementation had been extended independently. Factory rejected it because its bytes differed from the pinned release. This was a compatibility and admission problem, separate from the update incident.

The compatibility fix brought the bounded MCE lease consumer into the canonical maintenance source, verified its bytes before execution and included it in installation and rollback. Factory kept its exact-source checks; the two applications kept independent protection windows. Accepting an unknown helper would have hidden the mismatch rather than resolved it.

Verification and remaining limitations

The reviewed fixes passed focused policy, admission, rollback and compatibility checks. Ubuntu fixtures exercised package-manager integration with a fake package installer, needrestart configuration parsing and synthetic system services. Separate acquisition-recovery tests preserved native certification and historical failures.

These were scoped software checks, not a zero-downtime maintenance demonstration. The reviewed integration did not establish a successful live upgrade, reboot or production rollback, nor a completed long-duration campaign. Already admitted maintenance and explicit privileged bypasses remain outside protection.

What I now check

I now treat host maintenance as part of the collection lifecycle: what can interrupt a run, when deferred patches can proceed and which evidence must survive. Application safeguards did their job by refusing false continuity. Host policy needed to respect the same boundary.

Evidence basis: the private Factory maintenance incident account, bounded-maintenance documentation and merged maintenance, recovery and compatibility reviews. This is an original public explanation; private logs and host configuration are omitted.