[Purple10101]

Summary

sdrplay-restart.sh runs before blah2 on every container start and logs "Restarting SDRplay services... reset complete", but it has never restarted anything inside the container.

• pkill -9 -x sdrplay_apiService cannot match. Linux truncates a process name (comm) to 15 characters, so the service runs as sdrplay_apiServ. pkill warns about exactly this, but the warning went to /dev/null and the exit code was swallowed by || true. Before v0.3.0 the script used killall, which the image did not have, so this kill has never worked in the container.
• pkill -9 -x blah2 does match, but only the wrong thing. At a normal container start, blah2 is not running yet. With pid: host, the only blah2 it can find is one in another container.

This PR removes both kills and the misleading log lines. It keeps the 2 s pause and the file itself.

Why remove rather than fix

Resetting the SDRplay service belongs to the host side, which holds /data/retina-gui/restart.lock: retina-gui's apply and mode switches, and the owl-os watchdog. In almost every path that starts this container, one of them has just restarted the service. A kill that worked would add a second service restart with only a 2 s gap. retina-gui has documented that back-to-back pattern as wedging the device.

The pause stays because several host-side paths (the switch to radar, enforce_radar_mode, the watchdog) start blah2 straight after restarting the service, and this is their only gap. The file stays because retina-node's compose and this repo's compose call it by path.

Verification

Live on a test node (RSPduo, SDRplay API 3.15).

The old script, on the current image:

Check	Result
Service PID across a container restart	Unchanged (13340), although the log said "reset complete"
pgrep -x sdrplay_apiService from inside the container	"pattern ... longer than 15 characters will result in zero matches", rc 1
pgrep -f on the full command line	Finds the service (PID 13340), so the process is visible and only the name match fails
A decoy process named blah2 in a separate container	Killed (exit 137) when the production blah2 restarted
Pause before blah2 opens the device	2.06 s

The new script, mounted over the image's copy via the manifest:

Start path	Result
Plain container restart	Service PID unchanged (405472), the same as the old script
Config apply through retina-gui	retina-gui restarted the service; blah2 came up after the settle, NumDevs=1, 2.26 s pause
The owl-os watchdog script, run for real on a stale map	The watchdog restarted the service; blah2 came up, NumDevs=1, 2.22 s pause
Reboot	One silent first attempt then up (restarts 1), the same as the old script; NumDevs=1, 2.3 s pause

In every case, only the host side restarted the service, never the container. Not verified: a standalone install without the watchdog, where behaviour is unchanged too, since the kill never ran there either.

Docs

CLAUDE.md's "SDRplay Restart" section told people to run sudo ./sdrplay-restart.sh, which was a no-op on the host for the same reason. It now gives a sequence that works:

1. stop blah2
2. restart the service
3. settle
4. start blah2.

It also has the pkill -f fallback for when the service ignores SIGTERM, and says the script only pauses. The README does not mention the script.

Not in this PR

• retina-spectrum's start command has its own pkill -9 -f sdrplay_apiService, in retina-node's compose and in retina-spectrum's. That one is a no-op because pkill is not installed in its image. It is removed in separate PRs in those repos.
• Dropping the script call from the compose files, and the script itself, is a later cross-repo cleanup.

🤖 Generated with Claude Code