Cyclic asterisk restarts on stand alone nodes ? Usb read stuck - nope! - read stuck - nope! ad infinitum

App_rpt-users
1

Afternoon all,

So as part of my VOX demonstrator build (see other thread) I need to have a second node so that I can demonstrate DTMF based linking - just like the guy that invented the first telephone - he had to build a second! :slight_smile:

And the issue that I see must be something I’m doing in config as I have different PIs , soundfobs, and even tried beta 2 then regressed back to stable 1 as I am seeing it on both builds.

Problem summary - circa once a minute asterisk restarts on my second node. taking all registrations with it .

No matter how high I set console verbosity When it crashes I am booted out so no meaningful info can be gleaned from the console session.

Tailing /var/log/asterisk/messages I see (The ficticious node number is an off-grid private test network) :

[Feb 4 15:17:46] WARNING[19202] chan_usbradio.c: Possibly stuck USB read channel. [usb_16335]
[Feb 4 15:17:46] WARNING[19202] chan_usbradio.c: Nope, USB read channel [usb_16335] wasn’t stuck after all.
[Feb 4 15:18:37] NOTICE[19215] dnsmgr.c: Managed DNS entries will be refreshed every 300 seconds.
[Feb 4 15:18:37] NOTICE[19215] cdr.c: CDR simple logging enabled.
[Feb 4 15:18:37] NOTICE[19215] loader.c: 57 modules will be loaded.
[Feb 4 15:18:37] NOTICE[19215] ./xpmr/xpmr.c: xpmr rxlpf: 0
[Feb 4 15:18:37] NOTICE[19215] ./xpmr/xpmr.c: xpmr rxhpf: 0
[Feb 4 15:18:37] NOTICE[19215] ./xpmr/xpmr.c: xpmr txlpf: 0
[Feb 4 15:18:37] NOTICE[19215] ./xpmr/xpmr.c: xpmr txhpf: 0
[Feb 4 15:18:37] NOTICE[19221] app_rpt.c: Normal Repeater Init 16335
[Feb 4 15:18:37] WARNING[19238] chan_usbradio.c: Loaded parameters from usbradio_tune_usb_16335.conf for device usb_16335 .
[Feb 4 15:18:37] WARNING[19237] chan_usbradio.c: Possibly stuck USB read channel. [usb_16335]
[Feb 4 15:18:37] WARNING[19237] chan_usbradio.c: Nope, USB read channel [usb_16335] wasn’t stuck after all.
[Feb 4 15:19:27] NOTICE[19245] dnsmgr.c: Managed DNS entries will be refreshed every 300 seconds.
[Feb 4 15:19:28] NOTICE[19245] cdr.c: CDR simple logging enabled.
[Feb 4 15:19:28] NOTICE[19245] loader.c: 57 modules will be loaded.
[Feb 4 15:19:28] NOTICE[19245] ./xpmr/xpmr.c: xpmr rxlpf: 0
[Feb 4 15:19:28] NOTICE[19245] ./xpmr/xpmr.c: xpmr rxhpf: 0
[Feb 4 15:19:28] NOTICE[19245] ./xpmr/xpmr.c: xpmr txlpf: 0
[Feb 4 15:19:28] NOTICE[19245] ./xpmr/xpmr.c: xpmr txhpf: 0
[Feb 4 15:19:28] NOTICE[19251] app_rpt.c: Normal Repeater Init 16335
[Feb 4 15:19:28] WARNING[19268] chan_usbradio.c: Loaded parameters from usbradio_tune_usb_16335.conf for device usb_16335 .
[Feb 4 15:19:28] WARNING[19267] chan_usbradio.c: Possibly stuck USB read channel. [usb_16335]
[Feb 4 15:19:28] WARNING[19267] chan_usbradio.c: Nope, USB read channel [usb_16335] wasn’t stuck after all.

nothing in the event log.

I have seen this issue across 2 different PIs , with 3 different soundcards and 2 different builds

NODE 1 - Beta 2.x - present after 5 days
NODE 1 - Stable 1.x - now clear and stable for 3 consecutive days
NODE 2 - Stable 1.x - present on day 1 , still present
NODE 2 - Beta 2.x - not tested

Node 1 is a Pi3B
Node 2 is a Pi2B

I am convinced its config, and its clearly easily repeatable as I’ve managed to do it twice on 2 nodes.

Has anyone else seen this / root caused the challenge please ?

Its not CPU / RAM as top thinks I’m only consuming 2.8% CPU and less that 50% RAM

any clues ?

Regards

BB

2

While I’m not going to be much help, I would say you need to look for type errors.

But I might ask if you did any cut/copy paste editing your files,
and if you are editing files with a non-linux editor externally.

systemctl stop asterisk
will stop the procces to give you some time to look things over a bit without asterisk running.
systemctl start asterisk to start back up

You can look in ’ /var/log/asterisk/messages ’ for answers of what you are not seeing in foreground asterisk verbose window. My experiance is that a type error in the config files will not likely be clearly seen in the logs as it is some other event that errors before from something else not loaded or config properly, but it is a start as you find what is depndant on that first error.

**You might also want to verify the position of the sound fob **
lsusb
and check that with your config’d position simpleusb/usbradio file.
[usb_29285]
; name=usb_29285
; devicenum=1
devstr=4-2:1.0 <<<<<<<<<<<<<<<<<<<<<
rxmixerset=700
txmixaset=300
txmixbset=300
rxvoiceadj=1.10000
rxctcssadj=1.100000
txctcssadj=100
rxsquelchadj=400

When you give up, I would say, start with a fresh file, one at a time, starting with rpt.conf
Rename your old file for reference.

BTW
This was not the explained issue when top thinks commented on it.
poor question + poor data = poor answer.

3

Thanks Mike, but it was correct , after several more hours of looking I had gone
text blind!

Then it occurred to me…

I copied node 1 usbradio.conf to node 2 via SCP
edited and did a global find / replace in nano for the source and destination node numbers
saved it to /etc/asterisk and restarted the service

problem gone!

Would have been nice to find it, but more important to get the damned thing on air

Regards

BB

4

Gotta tell ya how many times I have had asterisk in a loop over the years.
My fingers are blind it seems. Go figure !

But keep that in mind when you unplug and replug the sound fob as well. At least on a PC. Sometimes it will switch positions while using the same physical port.
Plug and Prey is often the issue there.
I don’t think this happens on the Pi, I have not seen it anyway. Don’t use it much either.
Thanks for the follow up.

5

A trick to see what is the problem is to first shutdown you node. astdn.sh really works but make sure it’s not running.

Then do asterisk -fnvvv to start asterisk in the foreground. You’ll be able to see the entire startup sequence.