SDK ReleaseDevice() hangs forever after a stuck transfer — server cannot exit, camera needs a physical replug

[takusaito-ctrl]

Environment: ILCE-7M5 · USB · Camera Remote SDK V2.02.00 · linux-arm64 (Raspberry Pi, kernel 6.8.0-1051-raspi) · server 3.0.0

Summary

Once a RemoteTransfer download is stuck (#40), the process can no longer shut down. POST /api/server/shutdown runs teardown correctly right up until SDK::ReleaseDevice(), which then blocks indefinitely. The only escape is SIGKILL, which leaves the camera's USB session open so the body refuses all new connections until it is physically unplugged and replugged.

Reproduction

1. Trigger the stuck download from RemoteTransfer full-size download silently never completes and latches the whole subsystem into 0x8D03 #40.
2. POST /api/server/shutdown → 200 {"success":true,"message":"Shutdown initiated"}
3. Teardown proceeds correctly, then stops dead:

[Shutdown] Graceful shutdown requested via /api/server/shutdown
[Shutdown] Stopping web server...
Web server has been stopped.
[Shutdown] Beginning CameraWebController destruction...
Stopping CameraOperationWorker for camera: CFCA6014E092
Stopping LiveViewOSDWorker for camera: CFCA6014E092
CameraOperationWorker thread ended for camera: CFCA6014E092
LiveViewOSDWorker thread ended for camera: CFCA6014E092
[Shutdown] Worker threads stopped for camera: CFCA6014E092
[Shutdown] All worker threads stopped
[Shutdown] Clearing event callbacks on all cameras...
[Shutdown] Disconnecting camera CFCA6014E092...
[Shutdown] Warning: camera CFCA6014E092 disconnect timed out after 5s
[Shutdown] Releasing camera CFCA6014E092 handle...        <-- blocks here forever

4. Process state after 30s+, 7 threads still alive:

    PID STAT WCHAN                              ELAPSED CMD
  61016 Sl   futex_wait_queue                     19:14 ./CameraWebApp

The hang is inside Sony's ReleaseDevice(), not our teardown code — our own disconnect step has a 5s timeout and correctly gives up.

Confirmation of the cause

Physically unplugging and replugging the camera caused the blocked ReleaseDevice() to return and the process exited on its own, with no signal sent. That confirms it is waiting on the pending USB transfer rather than deadlocking internally on our locks.

Impact

This is the most expensive failure mode in the system, because recovery requires physical access to the hardware:

• SIGTERM does not kill it.
• SIGKILL works but leaves the USB session open — subsequent connects then fail with Connection did not complete within 15s until the camera is replugged.
• On a headless/remote rig, this bricks the deployment until someone walks over to it.

Suggested direction

• Put a bounded timeout around ReleaseDevice() the same way the disconnect step already has one, and proceed with process exit if it expires.
• Better: cancel/drain outstanding RemoteTransfer requests before attempting release, so there is nothing left to block on.
• usbreset 054c:0f56 is a viable Linux-side recovery and is worth documenting as an alternative to a physical replug.

[jordlee]

macOS data point: the SIGKILL aftermath is milder here, and needs no replug

Environment: ILCE-7M5 (CFCA6014E092) · USB · SDK V2.02.00 · darwin-arm64 · server 3.0.0

The ReleaseDevice() hang itself is not reproducible on macOS, because its trigger (#40's stuck transfer) does not occur here — see #40 (comment). The linux label is right.

But one specific claim in this issue does not hold on macOS, and it is worth recording because it affects how the recovery is documented. This issue states that after SIGKILL:

subsequent connects then fail with Connection did not complete within 15s until the camera is replugged

I SIGKILLed a server holding the camera in remote-transfer and measured what actually happens:

Action after SIGKILL	Result
Connect remote-transfer	fails, 0x00008219 (CrError_Connect_RemoteTransfer_NotSupported), 3.7 s
Connect remote	succeeds, 3.8 s
Then DELETE /connection, retry remote-transfer	succeeds
Plain server restart, connect remote-transfer	succeeds

So on macOS the leftover session is mode-specific and self-clearing: remote connects immediately, and any clean connect/disconnect cycle restores remote-transfer. No physical replug, no usbreset. The failure is also not the 15s message — it carries a real SDK code.

This suggests the replug requirement on the Pi may be entangled with the stuck transfer rather than with SIGKILL alone. That is a useful distinction for the fix: if SIGKILL by itself leaves a recoverable session on Linux too, then bounding ReleaseDevice() (as suggested here) plus draining outstanding transfers may be sufficient, and the "requires physical access" framing may only apply to the stuck-transfer case.

Worth testing on the Pi: SIGKILL a server holding the camera without having triggered a transfer, then try remote mode. If that connects, the replug requirement belongs to #40, not to this issue.

Also relevant to #39: 0x8219 renders as "Camera refused the connection", which is what made this state confusing to diagnose in the first place.