Can viewadsb be executed while readsb is running?

[jlpoolen]

I have readsb running on a Raspberry Pi 4B ("Rpi") (development box) using the adsbexchange.com (9/2022) image. I've logged into the Rpi and was able to run the command "viewadsb" successfully. I recall reading somewhere that only one program should access the USB transceiver at a time. My brief attempt to run viewadsb appeared not to present any problems. And my server for /tar/1090 appears unaffected and remains running. I thought I'd log an Issue with this question so there is a definitive statement:

Can viewadsb be run while readsb is running? Or should the two programs, viewadsb and readsb, not be run simultaneously?

When I run the command, it looks like readsb is called thereby causing two instances of readsb to interface with the USB transceiver (unless the code can detect a copy of itself already connected?):

 jlpoole@adsbDEV:~ $ viewadsb
 Wed May 15 15:34:43 2024 UTC  readsb starting up.
 readsb version: wiedehopf git: d809bd8 (committed: Wed Sep 7 13:47:41 2022 0200)
 jlpoole@adsbDEV:~ $

[Edit after closed] viewadsb = readsb, so this inquiry is simply about running a secondary, or greater number, of the same program: readsb. See Makefile line 162:

viewadsb: readsb
    rm -f viewadsb
    cp readsb viewadsb

But, see readsb.c at line 2097 where " // check if we are running as viewadsb and set according behaviour", so the naming of the program will necessarily determine certain parameters the program uses.

[jlpoolen]

For completeness, here is a screenshot of the viewadsb output:

[wiedehopf]

readsb only talks to the SDR if you tell it to.

viewadsb by default connects to localhost 30005 to get beast data.

[jlpoolen]

Here is filtered output from my dev server:

jlpoole@adsbDEV:~ $ ps -efww |grep read
root         2     0  0 May13 ?        00:00:00 [kthreadd]
tar1090    602     1  0 May13 ?        00:00:00 /bin/bash /usr/local/share/tar1090/tar1090.sh /run/tar1090 /run/readsb
tar1090    662   602  0 May13 ?        00:04:45 /bin/bash /usr/local/share/tar1090/tar1090.sh /run/tar1090 /run/readsb
jlpoole  25316  9103  0 16:04 pts/2    00:00:00 grep --color=auto read
readsb   31976     1 11 02:43 ?        01:30:46 /usr/bin/readsb --net-api-port 30152 --net-json-port 30154 --write-prom /run/readsb/stats.prom --gain 37.2 --lat 44.93652373649993 --lon -123.02178981948961 --device 1090 --device-type rtlsdr --ppm 0 --max-range 450 --net --net-heartbeat 60 --net-ro-size 1200 --net-ro-interval 0.1 --net-ri-port 30001 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005 --json-location-accuracy 2 --write-json /run/readsb --quiet
jlpoole@adsbDEV:~ $

So process 31976 is directly connecting to the the USB SDR by virtue of the command option "--device-type rtlsdr" and the other two processes presumably are connecting to ports specified in the command for for process 31976. Thus, the process, 31976, owned by readsb is the "master" process from which all other processes may access the stream, as well as any new instances which do not specifically try to utilize the "--device-type" parameter matching the previously captured device.

If the analysis above is accurate, then I'm good with closing this issue. Thank you.

[wiedehopf]

No that's not accurate.

beast data is something very specific and not what readsb gets from the SDR.

viewadsb will by default assume this command line:

viewadsb default: --net-connector 127.0.0.1,30005,beast_in viewadsb first usage overrides default, second usage adds another input/output)

readsb will not default to any data source.

net connector is just a network connection. you can run your main readsb with --debug=n to see other programs getting data.

[wiedehopf]

31976 is a readsb process with the pid 31976 that is using the SDR. It is running as user readsb.

You could say it's owning the SDR while it's reading from it ... as no one else will be able to read from the SDR. But ownership is a specific term so ... usage is problematic if it's not about the actual owner of a file.

[jlpoolen]

31976 is a readsb process with the pid 31976 that is using the SDR.

          31976  is a readsb process with the pid 31976 that is using the SDR.

Originally posted by @wiedehopf in https://github.com/wiedehopf/readsb/issues/70#issuecomment-2113009750

Correct.

jlpoole@adsbDEV:~ $ systemctl --type=service --state=running |nl
1    UNIT                       LOAD   ACTIVE SUB     DESCRIPTION
2    adsbexchange-feed.service  loaded active running adsbexchange-feed
3    adsbexchange-mlat.service  loaded active running adsbexchange-mlat
4    adsbexchange-stats.service loaded active running ADSBexchange Stats
5    avahi-daemon.service       loaded active running Avahi mDNS/DNS-SD Stack
6    bluetooth.service          loaded active running Bluetooth service
7    chrony.service             loaded active running chrony, an NTP client/server
8    collectd.service           loaded active running Statistics collection and monitoring daemon
9    cron.service               loaded active running Regular background program processing daemon
10    dbus.service               loaded active running D-Bus System Message Bus
11    dhcpcd.service             loaded active running DHCP Client Daemon
12    getty@tty1.service         loaded active running Getty on tty1
13    graphs1090.service         loaded active running graphs1090 graph generation
14    hciuart.service            loaded active running Configure Bluetooth Modems connected by UART
15    leds.service               loaded active running Use Pi LEDs for custom status indications
16    lighttpd.service           loaded active running Lighttpd Daemon
17    php7.4-fpm.service         loaded active running The PHP 7.4 FastCGI Process Manager
18    pingfail.service           loaded active running pingfail - restart dhcpcd when there is no internet
19    readsb.service             loaded active running readsb ADS-B receiver
20    rng-tools-debian.service   loaded active running LSB: rng-tools (Debian variant)
21    ssh.service                loaded active running OpenBSD Secure Shell server
22    systemd-journald.service   loaded active running Journal Service
23    systemd-logind.service     loaded active running User Login Management
24    systemd-udevd.service      loaded active running Rule-based Manager for Device Events and Files
25    tar1090.service            loaded active running tar1090 - compress dump1090 json data
26    triggerhappy.service       loaded active running triggerhappy global hotkey daemon
27    user@1001.service          loaded active running User Manager for UID 1001
28    wpa_supplicant.service     loaded active running WPA supplicant

29  LOAD   = Reflects whether the unit definition was properly loaded.
30  ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
31  SUB    = The low-level unit activation state, values depend on unit type.
32  27 loaded units listed.
jlpoole@adsbDEV:~ $

And 31976 (line 19 above) is the process launched by Systemd ("Service") as configured by the adsbexchange.com build. For posterity, while that Service was running, I attempted to launch my own session of readsb and the result was this message duly indicating the USB port was unavailable:

jlpoole@adsbDEV:~ $ readsb
Wed May 15 16:40:32 2024 UTC  readsb starting up.
readsb version: wiedehopf git: d809bd8 (committed: Wed Sep 7 13:47:41 2022 0200)
No networking or SDR input selected, exiting! Try '--device-type rtlsdr'! See 'readsb --help'
jlpoole@adsbDEV:~ $ readsb --debug=n
Wed May 15 16:40:45 2024 UTC  readsb starting up.
readsb version: wiedehopf git: d809bd8 (committed: Wed Sep 7 13:47:41 2022 0200)
No networking or SDR input selected, exiting! Try '--device-type rtlsdr'! See 'readsb --help'
jlpoole@adsbDEV:~ $ readsb --debug=n --device-type rtlsdr
Wed May 15 16:41:14 2024 UTC  readsb starting up.
readsb version: wiedehopf git: d809bd8 (committed: Wed Sep 7 13:47:41 2022 0200)
rtlsdr: error querying device #0: Permission denied
Wed May 15 16:41:14 2024 UTC  sdrOpen() failed, exiting!
Wed May 15 16:41:14 2024 UTC  Abnormal exit.
jlpoole@adsbDEV:~ $ sudo readsb --debug=n --device-type rtlsdr
[sudo] password for jlpoole:
Wed May 15 16:41:29 2024 UTC  readsb starting up.
readsb version: wiedehopf git: d809bd8 (committed: Wed Sep 7 13:47:41 2022 0200)
rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 1090)
usb_claim_interface error -6
rtlsdr: error opening the RTLSDR device: Device or resource busy
Wed May 15 16:41:30 2024 UTC  sdrOpen() failed, exiting!
Wed May 15 16:41:30 2024 UTC  Abnormal exit.
jlpoole@adsbDEV:~ $    

So on my adsbexhcange.com image, I would need to halt the Service (and thus kill the process, e.g. 31976) before attempting to run readsb with the parameter "--device-type rtlsdr". In other words, only one instance of readsb may "claim" the USB interface when using the parameter "--device-type rtlsdr".

(I'm including lots of text given this era of searches and Artificial Intelligence digestion.)