_proc
_proc
¶
Process-table reads shared by the supervisor's diagnostics.
The supervisor spawns one child per service, each identified by its own argv:
<python> -P -m terok_sandbox supervise-child <service> <id> <sidecar>
That argv is the only handle a later process has on those children. They
write no PID files of their own — the parent's covers the bundle — so
every question about which services are actually running is answered by
reading /proc, and this module is where that read lives rather than in
each of the three callers that ask (the uninstall sweep, the host
diagnostics, and the doctor's per-container checks).
Bytes, not text: /proc/*/cmdline holds arbitrary byte sequences for
foreign processes, and a decode error must not abort a sweep mid-flight.
CHILD_INVOCATION = (b'-m', b'terok_sandbox', b'supervise-child')
module-attribute
¶
PROC_DIR = Path('/proc')
module-attribute
¶
iter_process_argvs()
¶
Yield (pid, argv_elements) for every process whose cmdline is readable.
Source code in src/terok_sandbox/_util/_proc.py
iter_service_children()
¶
Yield (pid, service, container_id) for every live supervisor child.
Every child on the host, of every container — callers filter. A child
whose argv is truncated past the verb is reported with "?" for the
field it lost, because a process that is one of ours matters even
when it cannot say which one it is.
Source code in src/terok_sandbox/_util/_proc.py
service_children(container_id)
¶
The service names of the live supervisor children for container_id.
Sorted, so a caller can print or compare it without deciding an order. An empty tuple means no child of that container is running — which for a container whose supervisor is alive is the interesting failure: the parent survives its children, so a bundle can be half dead and look healthy from the PID file alone.