A wrapper's echo $$ put the shell's PID in the pidfile the deploy script trusted

`echo $$` returns the PID of the shell that runs it. The deploy wrapper wrote that number into worker.pid and then started python3 as a child, so the recorded PID belonged to a shell holding no queue connection ^[7]. The harness published with the field note keeps the defect on purpose. Its second file is commented "deliberately does NOT exec, mimicking the deploy wrapper" ^[14]. Skip the exec and the shell stays alive as the worker's parent. The PPID comparison in the post's diagnostic is what exposes that gap ^[19].

From there the shutdown ran in order: the deploy script sent SIGTERM to the PID in the file, the supervisor reported the service stopped and started a fresh instance, and the old Python process kept running, reparented to init, still holding its queue connection ^[6]. Two consumers drained the same queue, and neither knew the other existed ^[1]. The nightly job usually takes eleven minutes, and the metrics showed the same batch processed twice ^[2].

The first theory was a missing handler. The author installed `signal.signal(signal.SIGTERM, handler)` and logged every delivery ^[8]. "That changed nothing, which should have been decisive evidence instead of a puzzle," the author wrote ^[9]. The second theory was a stuck network read, so the code got timeouts everywhere and eventually a forced `os._exit`, and there were still two processes ^[10]. Both fixes went into the Python worker, the one process that was never sent a signal ^[21].

The check that resolves it is one line: `ps -o pid,ppid,pgid,sid,cmd -p "$(cat worker.pid)"` ^[11]. If the PID in the file resolves to an `sh` process and the Python PID has a different PPID, the answer is in front of you ^[11]. The same output carries the process group and session IDs, and the post says those will tell you whether `kill -TERM -PGID` would be a safe broadcast or a small disaster ^[12].

The harness makes the evidence binary. A start record with no signal record means the handler never ran, and the post calls that missing line "the difference between a logging problem and a supervision problem" ^[15]. On Linux you can also read the disposition directly: `/proc/<pid>/status` publishes SigCgt, SigBlk and SigIgn bitmaps, and the post's sigset.py decodes them into signal names ^[16]. Run it against both processes and "you will usually see SIGTERM in SigIgn or absent from SigCgt on one of them", the author wrote ^[17]. The post also flags PID 1, where the kernel does not apply default terminating actions ^[18].

This is one host and one deploy script, and the author describes the write-up as "a field note, not a tutorial about signal theory" ^[20]. Three conditions have to hold for it to be your bug: a pidfile written by a shell that does not exec, a deploy script that sends SIGTERM to whatever that file says, and a supervisor whose liveness answer comes from the same PID ^[6][7].