ASL3 Asterisk failing to start, code=dumped, status=11/SEGV

1

Two different ASL3 servers - RPI 3B+ and Wyse304 - are now refusing to start asterisk, either at boot or with start/restart command. Both use usbradio on simplex radios.

journal is giving the “Main process exited, code-dumped, status=11/SEGV” message.

Googling tells me this is a Segment Fault. Searching the archives here only turned up a Pi Zero install that wasn’t supported and an Echolink connect issue (without a resolution).

In both cases, a week ago on the RPi, and just an hour ago on the Wyse, both were functioning as expected. The RPi also supports a DVSwich install. They Wyse is just a single public node.

They both failed after issuing a “reboot” as root. Yes, a copy of the RPi SD card would have been a smart move, and an image of the Wyse. But such is not the case here. My intuition is that I’ll be starting over on both servers…unless someone has a magic place to deploy a fix.

The output from the asl-menu “diagnostics” report

Please wait…
Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)
Job for asterisk.service failed because a fatal signal was delivered causing the control process to dump core.
See “systemctl status asterisk.service” and “journalctl -xeu asterisk.service” for details.
Job for asterisk.service failed because a fatal signal was delivered causing the control process to dump core.
See “systemctl status asterisk.service” and “journalctl -xeu asterisk.service” for details.
Job for asterisk.service failed because a fatal signal was delivered causing the control process to dump core.
See “systemctl status asterisk.service” and “journalctl -xeu asterisk.service” for details.
Job for asterisk.service failed because a fatal signal was delivered causing the control process to dump core.
See “systemctl status asterisk.service” and “journalctl -xeu asterisk.service” for details.

root@Wyse3040:/home/k5jr# systemctl status asterisk.service
● asterisk.service - Asterisk PBX
Loaded: loaded (/lib/systemd/system/asterisk.service; enabled; preset: enabled)
Active: activating (start) since Thu 2025-02-27 18:13:23 EST; 753ms ago
Docs: man:asterisk(8)
Main PID: 2375 (asterisk)
Tasks: 3 (limit: 2236)
Memory: 24.1M
CPU: 747ms
CGroup: /system.slice/asterisk.service
├─2375 /usr/sbin/asterisk -g -f -p -U asterisk
└─2376 astcanary /var/run/asterisk/alt.asterisk.canary.tweet.tweet.tweet 2375

Feb 27 18:15:42 Wyse3040 systemd[1]: Starting asterisk.service - Asterisk PBX…
░░ Subject: A start job for unit asterisk.service has begun execution
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ A start job for unit asterisk.service has begun execution.
░░
░░ The job identifier is 5219.
Feb 27 18:15:45 Wyse3040 systemd[1]: asterisk.service: Main process exited, code=dumped, status=11/SEGV
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ An ExecStart= process belonging to unit asterisk.service has exited.
░░
░░ The process’ exit code is ‘dumped’ and its exit status is 11.
Feb 27 18:15:45 Wyse3040 systemd[1]: asterisk.service: Failed with result ‘core-dump’.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ The unit asterisk.service has entered the ‘failed’ state with result ‘core-dump’.
Feb 27 18:15:45 Wyse3040 systemd[1]: Failed to start asterisk.service - Asterisk PBX.
░░ Subject: A start job for unit asterisk.service has failed
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ A start job for unit asterisk.service has finished with a failure.
░░
░░ The job identifier is 5219 and the job result is failed.
Feb 27 18:15:45 Wyse3040 systemd[1]: asterisk.service: Consumed 1.854s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ The unit asterisk.service completed and consumed the indicated resources.

tnx
Mike / K5JR

2

Having asterisk crash is a poor way to say “something is wrong”.

For starters, I would suggest checking the log files in the “/var/log/asterisk” directory.

Have you recently made changes to any of the configuration files in the /etc/asterisk directory? If so, can you make a copy of the file(s) that you changed and then undo your changes?

3

Hi, Allan. Thanks for your reply.

I’ve been doing AllStar since 2105, beginning with distros burned to CD/DVDs to load into an x86 PC. My first small SBC was/is on the BeagleBoneBlack. It’s still running. I later was able to install N4IRS’ true ASL on another BBB once that was available. I currently have 9 ASL units operating here at the house - 6 RPi and 3 Wyse3040.

Yes, I looked through approximately 15,000 lines of log files across 3 different ASL3 servers. The only things found were entries indicating asterisk was starting and then shortly thereafter that asterisk failed to start. No indication of which module was throwing up - just failed to start.

I even rendered a 3rd ASL3 RPi server from starting asterisk while mating it to the radio I had been using on a previous ASL 2 server.

This 3rd server provided the solution for all three - an old nemesis. I remembered that I had been down a similar issue in my early days with AllStar when I implemented USBRadio for the first time after previously using only Simple USB. Back then, I was using a tone already included in the usbradio.conf file - specifically 100.0. I needed to change the tone to a different one and added the tone to the rxctcssfreqs. I don’t recall asterisk not starting then, but the decode operation using the new tone didn’t work. I was using the radio to generate the TX tone, so no corresponding entry was made to txctcssfreqs. It turned out then, and now, that the two, rxctcssfreqs and txctcssfreqs tone entries must match exactly in order for ASL3 asterisk to start. I confirmed this to be true even if txmixa=voice and txmixb=no, meaning ASL3 is not being asked to source a CTCSS tone to the radio.

In reading all of the wikis and community posts related to usbradio, I have now discovered a single entry in Oct 2011 (9033 & 9033/2 ?) titled “Asterisk Bombs after startup”. The solution offered was to indeed make sure that rx tones and tx tones matched. What is of particular note about that post is the ERROR message in the OP - ERROR: numrxcodes != numtxcodes. I searched my log messages again and this ERROR message does not appear in any of the three ASL3 servers. A sample of the only ERRORs for usbradio in my log file:

[2025-03-01 23:12:50.128] ERROR[1771] chan_usbradio.c: Channel 29934: Unable to create new usb channel
[2025-03-01 23:12:50.128] ERROR[1771] app_rpt/rpt_bridging.c: Failed to request Radio/29934
[2025-03-01 23:35:11.626] ERROR[2319] chan_usbradio.c: Channel 29934: Unable to create new usb channel
[2025-03-01 23:35:11.626] ERROR[2319] app_rpt/rpt_bridging.c: Failed to request Radio/29934
[2025-03-01 23:41:00.523] ERROR[2520] chan_usbradio.c: Channel 29934: Unable to create new usb channel
[2025-03-01 23:41:00.524] ERROR[2520] app_rpt/rpt_bridging.c: Failed to request Radio/29934
[2025-03-01 23:43:03.119] ERROR[2629] chan_usbradio.c: Channel 29934: Unable to create new usb channel
[2025-03-01 23:43:03.119] ERROR[2629] app_rpt/rpt_bridging.c: Failed to request Radio/29934
[2025-03-01 23:50:46.136] ERROR[2981] chan_usbradio.c: Channel 29934: Unable to create new usb channel
[2025-03-01 23:50:46.136] ERROR[2981] app_rpt/rpt_bridging.c: Failed to request Radio/29934

I offer two recommendations, unless they already exists and I just couldn’t find them, and a feature request.

Recommendations
First, add to any wiki and documentation that rxctcssfreqs and txctcssfreqs must match exactly.
Second, re-institute the ERROR message for those instances when they don’t match.

The feature request is to allow for the rx and tx tone to be different in usbradio. There are repeater locations where I (and many others) must (or chose to) encode a different tone than the one used for decode. If this capability already exists in usbradio, please point me to the configuration settings. Otherwise, it’s SimpleUSB only for this scenario.

The ASL3 update is wonderful.

tnx
Mike / K5JR (formerly W5JR, and in the Community posts with the former call)

4

Just throwing this in there… The RX and TX tones in USBRadio were never intended for split tone operation. They were only ever intended to emulate the simplest of multi-tone community panels, where the uplink tone used by a user would result in the repeater using the same tone on it’s downlink. rxctcssfreqs and txctcssfreqs are just a list of “allowed” tones - but they must must match because if there is a tone in the RX list that is not in the TX list, then USBRadio won’t know what to do if/when it receives that tone.

Just letting you know how it was originally implemented. I do agree that this is a crappy way to set it up and a crappy way for it to work.

I’m not sure why there are two different settings (rxctcssfreqs and txctcssfreqs) instead of just a single ctcssfreqs, if they must be the same.

There should be a way to map RX tones to TX tones one-by-one.

Config could look like this:

; List of one or more (RX, TX) CTCSS tone combinations to use.
; For basic single-tone operation, use something like 141.3, 141.3.
; Get creative to allow split tones, multi-tone operation.
ctcssfreqs =
    141.3, 141.3
    131.8, 131.8
    88.0, 67.0
    100.0, 123.0

; Default CTCSS tone to use when transmitting without a valid RX CTCSS tone present
; For telemetry, announcements, etc.
defaulttxctcss = 100.0

Maybe this should go in the feature request list that was started recently…

5

'tis a good find.

On the top of my list is to actually fix the crash (and I already see one place in the code that’s problematic). I will also ensure that we have a nice log message if the lists have different sizes. And, of course, I can add a comment in the rpt.conf file.

Can you create a GitHub app_rpt Issue with your feature request?

6

@Mason10198 Great comments … and I like your config idea.

7

FYI : I just filed GitHub (app_rpt) Issue #526

8

Ok, so is it the size of rxctcssfreqs and txctcssfreqs that must match exactly, or the content?

If it’s the content, then my previous comments stand.

If it’s the size, then I question whether “mapping” is already implemented, and the documentation/config comments just need an overhaul. For example…

txctcssfreqs = 100.0, 123.0
rxctcssfreqs = 123.0, 100.0

Does this result in a split-tone repeater that TXs 100.0 when it RXs 123.0, and vise versa?

9

Thanks @WA3WCO and @Mason10198 for the comments. Allan, since you entered a GitHub issue, do you still need one from me?

@Mason10198 , I like your concept for valid tone pairs, thus allowing decode and encode to be different but specifically paired, just as decode and encode are for the same tones. I need to test your theory about size of entry versus actual content.

Allan, so what/where do these two cop codes interact with usbradio? I’ve not tested, but the intuition is that default Tx CTCSS is set to a value where stuff like ID messages are transmitted without generating any tone, as many other controllers can do.

Also note there’s a typo in the cop 58 line in the rpt.conf default file.

; 958 = cop.58 ; Tx CTCSS On Input only Enable
; 959 = cop,59 ; Tx CTCSS On Input only Disable

tnx
Mike / K5JR

10

FYI, @Mason10198 is correct. Any combination of Rx tone can be paired to a Tx tone. It is specifically that the number of Rx tones must match the number of Tx tones to be valid (as the old ERROR msg reports). I entered 5 different Rx tones (a mix of xxx.x and xx.x) and set all 5 Tx to 100.0. Asterisk loads and works as expected.

tnx
Mike / K5JR

11

The errant code that I found will likely crash if you have more rxctcssfreqs than txctcssfreqs. I did not look any further into how the freqs are used.

12

Well… I guess this depends. At this time I can’t answer the question about how the freqs are used but if the rxctcssfreqs and txctcssfreqs are, in fact, paired (i.e. 1->1, 2->2, …) then there’s no need for a another issue as support would already be present. But, if that’s not how things work today (please experiment and let us know) … or if you’re looking for a new way to express the pairs … then, yes, please create a new issue.

13

I don’t know.

Good catch.

14

Alright, so TL;DR…

Number of RX tones and number of TX tones must be the same. Worded differently, there must be a TX tone for each and every RX tone.

“Pairing” or “mapping” is probably already implemented, but needs to be verified. If I’m right, then this config would result in…

  • an uplink of 100.0 resulting in a downlink of 123.0
  • an uplink of 123.0 resulting in a downlink of 100.0
  • telemetry and announcements (no uplink tone present) transmitted with a downlink of 67.0
txctcssdefault = 67.0
txctcssfreqs = 100.0, 123.0
rxctcssfreqs = 123.0, 100.0

So it looks like my earlier example/feature request is actually how it works already.

In this case, we just need better documentation and explanation in the default/sample config files.