maziggy 562e325972 fix(camera): drain ffmpeg's pipes during teardown (#NNNN) ...

Closing a camera view logged "ffmpeg didn't terminate gracefully,
    killing" followed by "ffmpeg did not exit within 2.0s of SIGKILL;
    abandoning wait", on every single close. Both waits expired every time,
    so teardown took a fixed 4.00s -- and since the firmware allows one
    camera connection, that was 4s in which nothing else could use it.

    ffmpeg is spawned with stdout and stderr as pipes and the teardown paths
    have stopped reading them, so it sits blocked in write() on a full 64 KiB
    pipe. SIGTERM cannot be acted on there: the handler only sets a flag that
    the main loop polls, and the loop never gets back to the check. SIGKILL
    does kill it, but asyncio resolves Process.wait()'s waiter through
    _try_finish(), which requires every pipe transport to report
    disconnected; paused, unread pipes never reach EOF, so wait() blocks with
    returncode already set. A negative-control test shows returncode=-9 at
    the instant the abandon fires.

    Draining both pipes while stopping the process fixes both halves: 4.00s
    becomes ~0.15s. The signal ladder and its bounds stay as backstops, so a
    genuinely wedged process still cannot hang a stream, a Stop request or
    the janitor.

    This corrects _FFMPEG_KILL_TIMEOUT's premise and #2580's conclusion. That
    12-hour hang was the unbounded form of this same self-inflicted stall, not
    an ffmpeg stuck in uninterruptible I/O -- the process observed doing it
    was in state S, which cannot survive a delivered SIGKILL. Bounding the
    wait capped the symptom without removing the cause.

2026-08-02 09:40:04 +02:00

..

routes

fix(camera): drain ffmpeg's pipes during teardown (#NNNN)

2026-08-02 09:40:04 +02:00

__init__.py

Added screenshots

2025-11-28 10:23:59 +01:00