Updated SDRPlay API
Closed this issue · 20 comments
Just a heads up, the Linux SDRPlay API jumped to 3.12. So far it seems like applications previously running with 3.07 (after rebuilding) run okay. May want to consider pulling and using this.
I see you made a sdrplay api change, then I go look just now on the sdrplay page and what do I see.. 3.14. Did they really just push a completely new one?
Ridiculous! They did. Updated again - thanks for bringing it up!
It could be just me but I finally got around to pulling down your latest again today, blowing aways all containers/inages, had 3.14 on host.. but when doing compose up to run and test I get a seg fault every time right after it talks about getting the web api online but right before it says setting up RSPDUO.
It also immediately kills the host sdrplay api to the point I go into os auxx kill -9 and restart it. Otherwise trying to find the duo with soapy just sits there and hangs and no applications can use the sdrplay.
Strange
Try this;
sudo docker compose down
sudo docker system prune -a
sudo docker network create blah2
sudo docker compose up -d —build
If it still seg faults, try using my SDRplay reset script;
sudo ./script/blah2.sh
I’ll rebuild tonight - I didn’t update my host SDRplay so it may be an issue.
I did update my host SDRplay and rebuilt as above - came up the first time.
Let me know how you go?
Sadly so far it’s the same result for me, not exactly sure why. That’s after the prune and rebuild. I’ll keep trying to see what could possibly be different on my end.
Chuck some print statements in blah2.cpp and find the line causing the problem, since it builds correctly?
std::cout << "a" << std::endl;
Then
sudo docker compose down
sudo docker compose up -d --build
I'll start adding the statements asap. This is what I see when starting things up, I check prior to starting that the DUO is seen.
✔ Container blah2-web Created 0.1s
✔ Container blah2-api Created 0.1s
✔ Container blah2 Created 0.0s
Attaching to blah2, blah2-api, blah2-web
blah2 | Setting up device RspDuo
blah2-api | Running on http://0.0.0.0:3000
blah2-web | AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.18.0.2. Set the 'ServerName' directive globally to suppress this message
blah2-web | AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.18.0.2. Set the 'ServerName' directive globally to suppress this message
blah2-web | [Fri Feb 16 01:37:14.301030 2024] [mpm_event:notice] [pid 1:tid 139797663442816] AH00489: Apache/2.4.58 (Unix) configured -- resuming normal operations
blah2-web | [Fri Feb 16 01:37:14.301557 2024] [core:notice] [pid 1:tid 139797663442816] AH00094: Command line: 'httpd -D FOREGROUND'
blah2 | Segmentation fault (core dumped)
blah2 exited with code 139
blah2 | Setting up device RspDuo
So here's an interesting result. I start up docker, don't background it so I can see the segfault. Then I open two more windows, one I -9 kill the sdrplay service so it restarts and the Duo is seen by the host. Second window I drop into the blah2 container bash, go into the bin folder and run blah2 --config ../config etc etc and guess what, all is well inside the docker itself as it starts up with no issues and I look back over at the window that had the docker compose up going and I see the blah2-api numbers increasing.
I'm not sure why for me it's just all dying initial with the docker compose up.
Docker versioning problem perhaps? Could always try updating Docker to the latest version from their package repo:
https://docs.docker.com/engine/install/
And you are using docker compose instead of docker-compose?
docker compose yes and installed from their repo. V2.24.5
oddly enough this never happened before so I’m trying to see what may have changed.
I take that back. I was checking docker compose version on another PC that was V2.24.5 and it in fact did not have the segmentation fault after I typed what I said above.
I then ran sudo apt upgrade and can see it pulled in
Preparing to unpack .../08-docker-ce-cli_5%3a25.0.3-1ubuntu.22.04jammy_amd64.deb ...
Unpacking docker-ce-cli (5:25.0.3-1ubuntu.22.04jammy) over (5:25.0.2-1ubuntu.22.04jammy) ...
Preparing to unpack .../09-docker-ce_5%3a25.0.3-1ubuntu.22.04jammy_amd64.deb ...
Unpacking docker-ce (5:25.0.3-1ubuntu.22.04jammy) over (5:25.0.2-1ubuntu.22.04jammy) ...
Preparing to unpack .../10-docker-ce-rootless-extras_5%3a25.0.3-1ubuntu.22.04jammy_amd64.deb ...
Unpacking docker-ce-rootless-extras (5:25.0.3-1ubuntu.22.04jammy) over (5:25.0.2-1ubuntu.22.04jammy) ...
And now I have the segmentation fault like the other computer. I mean some other things were updated in the upgrade, but that stood out to me.
This is now what I show with just docker version. I'll go to yet another computer that does not have the upgrade yet. So likely nothing to do with the sdrplay api, but something happened with docker maybe?
dragon@dragon:/opt/blah2$ docker version
Client: Docker Engine - Community
Version: 25.0.3
API version: 1.44
Go version: go1.21.6
Git commit: 4debf41
Built: Tue Feb 6 21:13:09 2024
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 25.0.3
API version: 1.44 (minimum version 1.24)
Go version: go1.21.6
Git commit: f417435
Built: Tue Feb 6 21:13:09 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.28
GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
I was running 24.0.6 and updated to 25.0.3 like you. Did the full rebuild with prune and seems I'm getting the same as you.
Setting up device RspDuo
Error connecting to endpoint: connect: Connection refused
terminate called after throwing an instance of 'std::system_error'
what(): connect: Connection refused
Aborted (core dumped)
Setting up device RspDuo
For now try downgrading, but I'll investigate a fix.
This is really frustrating - I thought if I change the docker-compose bind mount from /dev/shm:/dev/shm to /dev/shm:/dev/shm:z to add write access it would work, but it didn't.
For now I'm reverting to Docker 24.0.9 and it's working.
https://docs.docker.com/engine/install/ubuntu/
VERSION_STRING=5:24.0.9-1ubuntu.22.04jammy
sudo apt-get install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl restart docker
That’s always so annoying that things just up and change and completely break everything. I’m wondering what else across the board docker project wise did it break.
I’m just going to revert, but did you see in there it talked about adding something to make the behavior pre 25 style?
I think it makes /dev/shm read only by default when it should be read/write (that's why I was playing around with the z flag. I'll have another attempt tomorrow. Let me know how you go reverting?
Works perfectly fine with latest code with docker downgraded!