Avoid a blocking fallback write in the signal handler

When stdout is a pipe whose buffer is full—the same backpressure scenario that can leave the main thread interrupted inside its original write—this os.write blocks rather than raising, so neither the surrounding except nor _release_and_die's finally can run. A cancellation can therefore hang before release() and leave the Kaggle kernel billing until an external hard kill; the signal-safe path should skip the diagnostic or make the descriptor nonblocking.

Useful? React with 👍 / 👎.

Correct, and worse than I had it: the announcement is the FIRST thing the handler does, so a stalled write sits ahead of release() entirely. Raising was the only failure mode I covered, and blocking is not an exception, so no except and no finally saves it. The kernels then bill until something kills the launcher from outside, which is the one outcome this file exists to prevent. Your point about the two arriving together is the part I had missed: the backpressure that fills the pipe is also what leaves the main thread parked mid-write, so the reentrancy and the stall are the same runner condition.

Fixed in 24e4500. _log_from_signal now asks whether the descriptor is writable before touching it, and drops the line if not. POSIX reports a pipe writable only when at least PIPE_BUF bytes fit and these lines are far shorter, so a positive answer means the write completes; any error from select answers no. I took the skip rather than the nonblocking descriptor because O_NONBLOCK lives on the open file description, which dup shares, so setting it would change the main thread's writes too.

The new test reproduces it rather than simulating it: the launcher writes until the pipe is full and the test never reads a byte, so the main thread is asleep inside a write holding the buffer lock when SIGTERM lands. Remove the guard and it hangs the whole 120s death budget with the kernel never deleted. 536 kaggle tests pass.

Make cleanup logging nonblocking too

When stdout is full and a deletion raises or returns a nonzero status, this call enters release(), whose delete_kernel() path still reports failures through the blocking _log; the handler therefore stalls before reaching its retry or finally, so the process does not die and the kernel can remain billable. The full-pipe regression test misses this because its fake deletion succeeds without logging. Fresh evidence in this revision is that only the handler's direct diagnostics use _log_from_signal, while logging transitively reached through release() remains buffered and blocking.

Useful? React with 👍 / 👎.

Correct on both halves, including the one about my test. The fake deletion succeeded silently, so nothing in it ever reached a _log the handler did not call itself.

Fixed in 6c4891b at the choke point rather than per call site: _log now drops instead of stalling whenever a module flag the handler sets on entry is true, so every line printed from that point on is covered however it was reached, release() and delete_kernel() included. The ordinary path is unchanged, which is every line this script prints before something kills it.

The test now logs on the way through the deletion, which is what a refused delete actually does. Remove the _log guard and it hangs the full 120s budget with the kernel never deleted, and the previous commit's fallback guard does not save it, which is your point exactly. 536 kaggle tests pass.

Suppress reentrant failures from cleanup logging

When a signal interrupts a write while sys.stdout holds its buffer lock but fd 1 remains writable, this check passes and print() raises RuntimeError: reentrant call; unlike handler-owned calls wrapped by _log_from_signal, the ordinary _log calls reached inside delete_kernel() propagate through release(). If Kaggle rejects the first two delete calls but would accept its configured third retry, each of the handler's two release() attempts instead aborts after one log failure, so the third deletion is never attempted and the kernel may remain billable. Fresh evidence after the prior fix is that the new _log guard handles backpressure but still does not swallow the reentrancy failure on the transitive cleanup path.

Useful? React with 👍 / 👎.

Also correct, and this is the sharper of the two: dropping a line and swallowing a failure are different guarantees, and I had only added the first. With the descriptor writable but the buffer lock held, print() raises, and on the transitive path that exception leaves delete_kernel(), leaves release(), and takes the remaining retries with it. Your example is the case that costs money: Kaggle refuses twice and would accept the third, and the third never happens.

Fixed in the same commit. _write_line now routes through the signal-safe path whenever the handler is running, so a line reached from anywhere is dropped on a full pipe and swallowed on a reentrant one, and neither can leave the retry loop.

The test refuses the first two deletes, accepts the third, and makes every write raise while the handler runs, so all three attempts only happen if the failure is contained where it occurs. Reverting the routing reproduces your description exactly: release() failed under signal 15: RuntimeError: reentrant call inside <_io.BufferedWriter ...> for both attempts, with the kernel left in the registry.

Route the unreleased-kernel warning through the safe logger

When stdout is already full as the handler starts and a deletion ultimately returns false, this guard drops the _log calls but release() subsequently emits its leaked warning with the direct blocking print() at lines 1143-1149. The handler then stalls before its finally can restore and re-raise the signal, leaving the failed kernel running; the new full-pipe test does not exercise this branch because its fake deletion succeeds, so leaked stays empty. Fresh evidence after the prior cleanup-logging fix is this remaining output path that bypasses _log entirely.

Useful? React with 👍 / 👎.

Correct. That print() is on exactly the branch where a kernel is still billing, so it is the worst place left to stall, and your note that the full-pipe test could not reach it is right: its deletion succeeds, so leaked stays empty.

Fixed in 65064c3, with one wrinkle worth flagging. Routing it through _log would emit [launch] ::warning ..., and GitHub matches an annotation from the START of the line, so that would have silently demoted the one message that tells a human a kernel is still running. The split is now between what a line IS and how it is written: _write_line carries the protections, _log adds the prefix on top, and this warning goes through _write_line directly.

New test drives a launcher whose deletes never succeed with a full pipe, and it must still die of SIGTERM. A second test reads the warning back out of a real main() run and asserts it still starts with ::warning; my first version of that called the writer directly and passed on the mutation it was meant to catch, so it now goes through release().