Skip to content

thingino-motors: fix S59motor stop path wedging motors-daemon - #1511

Open
catongates wants to merge 1 commit into
themactep:masterfrom
catongates:fix/s59motor-stop-wedge
Open

thingino-motors: fix S59motor stop path wedging motors-daemon#1511
catongates wants to merge 1 commit into
themactep:masterfrom
catongates:fix/s59motor-stop-wedge

Conversation

@catongates

Copy link
Copy Markdown

Fixes #1510.

What's wrong

S59motor's stop_daemon could never actually kill motors-daemon: the daemon self-daemonizes under -d (double-fork + setsid), so the PID start-stop-daemon -m records is the intermediate child, which exits immediately — the pidfile is stale from the moment it is written. stop() didn't check the result and ran rmmod motor anyway, which succeeds against the still-live daemon because motor_fops lacks .owner = THIS_MODULE (module use count stays 0 with a live opener — filed separately as themactep/ingenic-sdk#45). That leaves motors-daemon in permanently uninterruptible D state, immune to SIGKILL, recoverable only by a power cycle.

Full detail and live reproduction in #1510.

What this changes

  • stop_daemon now matches the real process (anchored on the binary path — an unanchored pkill -f pattern also matches the invoking shell) and escalates SIGTERMSIGKILL with a bounded wait, returning a real status.
  • stop() now refuses to rmmod unless the daemon is confirmed gone, turning the failure mode from an unrecoverable wedge into an ordinary loud error.

Both changes are scoped to stop_daemon()/stop(); nothing else in the file is touched.

Testing

Live on an Eufy E220 (T8410C, T31X, ciao+f433166): the exact S59motor restart that previously wedged the daemon now completes cleanly, with the daemon healthy afterward and motors -j responsive. Reproduced (and now fixed) on both motion_driver: legacy and profiled, so this is unrelated to the acceleration settings, which were the original — wrong — suspect.

# /etc/init.d/S59motor restart
Stopping motors
Setting up motors
Set GPIO per motor phase
Load motor module with parameters: hmaxstep=4100 vmaxstep=1150 ...
Home motors
Move to 2050,450
# ps w | grep motors-daemon
30645 root      1132 S    /usr/bin/motors-daemon -d -p
# motors -j
{"status":"0","xpos":"2050","ypos":"450","speed":"900","invert":"0"}

Investigated, tested, and drafted by an AI assistant while looking into PTZ motion behavior on this camera.

stop_daemon() could never actually stop motors-daemon: the daemon
self-daemonizes under -d (double-fork + setsid), so the PID
start-stop-daemon records via -m is the intermediate child, which
exits immediately -- the pidfile is stale from the moment it is
written. stop() didn't check stop_daemon's result and proceeded to
rmmod anyway, which succeeds against a live daemon because motor_fops
lacks .owner = THIS_MODULE (module use count stays 0 with a live
opener; filed separately as themactep/ingenic-sdk#45). That leaves
motors-daemon in permanently uninterruptible D state, immune to
SIGKILL, recoverable only by a power cycle.

Fix: stop_daemon now matches the real process (anchored on the binary
path, since an unanchored pattern also matches the calling shell) and
escalates SIGTERM -> SIGKILL with a bounded wait, returning a real
status. stop() now refuses to rmmod unless the daemon is confirmed
gone, converting the failure mode from an unrecoverable wedge into an
ordinary loud error.

Tested live on an Eufy E220 (T8410C, T31X): the exact restart that
previously wedged the daemon (reproduced on both legacy and profiled
motion_driver, so unrelated to acceleration settings) now completes
cleanly and leaves the motor responsive.

Fixes themactep#1510.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

S59motor stop path cannot kill the motor daemon (stale pidfile), then rmmods the module out from under it

1 participant