Motion Watchdog timeout

[bad-friday]

Always get «motion_watchdog: Thread 1 - Watchdog timeout did NOT restart, killing it» after a few minutes

Pi5 4GB, PI-HQ-Camera, Bookworm, motion 4.6.0 build from source on 15th December 2023.
log.txt

[tosiara]

How do you run motion?
Can you check if any solution from this thread works for you?
#1722 (comment)

[bad-friday]

As far as I can see they are talking about webcams and not on Bookworm.

[tosiara]

the comment I linked specifically mentions bookworm and libcamerify

[bad-friday]

Apparently I was able to solve the problem. The resolution is now 1920x1440. I changed the video device to video1, mmalcam_name to vc.ril.camera, movie_quality to 0, movie_bps to 4000000. Motion has been running for more than an hour now.
Edit:
After 2.5 hours it happened again

[bad-friday]

I think I'll give up and put the Pi 4 with Bullseye back into operation.
I've already spent days trying to get Motion running under Bookworm.

[bad-friday]

But now I'm angry.
The Computer from Raspberry, HQ camera from Raspberry, OS from Rapberry. But Motion doesn't work with it.
Configaration unchanged Raspberry-V3 Camera connected Motion started, which has now been running for more than three hours without an interruption.

[brainspin]

Same symptom here on a Pi 5 + HQ camera (IMX477), and I think I can narrow where it stalls. It looks like it is below Motion, not in it.

Setup: Pi 5 (8 GB), Debian 12 aarch64, kernel 6.12.93+rpt-rpi-2712, libcamera 0.5.2+rpt20250903 with the libcamera-v4l2 shim (libcamerify), rpicam-apps 1.9.0, Motion 4.5.1-2 (via motionEye 0.44), 1280x720 at 5 fps.

Symptom: the capture thread stops delivering frames, then motion_watchdog: Thread 1 - Watchdog timeout did NOT restart, killing it!; the stream port stays open but sends 0 bytes. Nothing in dmesg, the journal or libcamera's log. About 30 times a day at 5 fps (about one per 1-2 h while events are recording; 15 fps gave about one per 4 min). Most hangs start about 6 s after a motion event begins.

Evidence (70+ snapshots taken by a watchdog at the moment of the stall, before restarting):

1. The capture thread is blocked in ioctl() -> v4l2-compat -> pthread_cond_wait (no timeout). libcamera's CameraManager thread is idle in ppoll; no other thread is blocked.
2. libcamera logged nothing: no "Camera frontend has timed out", no dequeue-timer expiry, no cancelled requests (0 in 13 of 13 snapshots where the log was captured).
3. rp1-cfe interrupts keep counting but at exactly half the healthy rate (+30 per 3 s versus +60).
4. pispbe interrupts do not move at all (delta 0 in all 34 snapshots that sampled it; healthy is +30 per 3 s). The ISP back-end stops completing while the CSI receiver is still running.
5. Ruled out: hook processes (none exist at the hang), the movie encoder (x264 threads idle), the web server, CMA (55 of 64 MB free), CPU/thermal/power, kernel messages.

Control: rpicam-vid alone (same sensor mode, 1280x720 at 5 fps, H.264) ran 3 h with 0 stalls. Then I stopped using the shim: rpicam-vid | ffmpeg -c copy into an RTSP server on loopback (mediamtx), with Motion reading it as a network camera, no libcamerify. That has now run about 3.5 days with no capture stall (before: about 30 a day). So the sensor, CSI receiver, kernel and ISP are fine under that load; the stall needs the way Motion drives libcamera through the shim.

What I don't know: I have no reproducer without Motion (a bare V4L2 client under libcamerify was not tried), and I can't say whether the shim misses a completion or libcamera never completes the request (evidence 2-4 point at the second). I did not try Trixie's libcamera 0.7.2; the shim's wait logic looks the same there.

Workaround: don't use the shim: feed Motion a network camera from rpicam-vid over RTSP. Happy to run extra logging or a patched libcamera/v4l2-compat on this box; it reproduced within about 2 h on the old path.