but after a few reloads with PJSIP when i use TLS/SRTP with a yealink T48S phone then Asterisk crashes.
First a few thousand lines like this:
[2017-10-24 23:25:57] WARNING[30968] media_index.c: Failed to stat /var/lib/asterisk/sounds/en_GB/pbdirectory-if-correct-press.sln: No such file or directory
[2017-10-24 23:25:57] WARNING[30968] media_index.c: Failed to stat /var/lib/asterisk/sounds/en_GB/pbdirectory-if-correct-press.sln16: No such file or directory
[2017-10-24 23:25:57] WARNING[30968] media_index.c: Failed to stat /var/lib/asterisk/sounds/en_GB/pbdirectory-if-incorrect-press.sln: No such file or directory
[2017-10-24 23:25:57] WARNING[30968] media_index.c: Failed to stat /var/lib/asterisk/sounds/en_GB/pbdirectory-if-incorrect-press.sln16: No such file or directory
[2017-10-24 23:25:57] WARNING[30968] media_index.c: Failed to stat /var/lib/asterisk/sounds/en_GB/pbdirectory-welcome-to-phonebook.sln: No such file or directory
As mentioned in the original post, I was running 13.17.0.
That said, I’m on 13.17.2 now and haven’t had a crash yet. BUT, I’ve intentionally spread the extensions to a couple other servers, as to lower the load, which lowered the crashing frequency to once a week, then lowered it more until no crashing for about three weeks. Still had another crash about three weeks later.
Since on 13.17.2, we haven’t had any more, but it’s only been about a week. I’m going to move all the extensions back over to the one server and see if the increased load causes another crash on this newer version of Asterisk.
Thanks Dicko. However, we’ve experienced the issue on 13.15 as well. So it’s hard to decide what’s safe. Go to current 14 version?
Also, our procs are CPUs24 x Intel® Xeon® CPU E5-2620 and CPUs24 x Intel® Xeon® CPU L5640, and both seemed to be supported by CentOS 6.6, so that theory’s out the window.
Personally, I have found that using 13. pretty well anything with cdr-mysql will cause that , update to odbc, unload the cdr mysql stuff and maybe . . . ., but yes my machines are quite happy now under 13.18.rc? or 14.6.2 under ProxMox or Vultr ( both have been a PITA for a few months)
So we had another FRACK finally. It now does appear that the “Serious Network Trouble” Error issue we’ve been having seems related. Here’s part of our log:
[2017-11-11 06:03:50] WARNING[8721] chan_sip.c: Unable to cancel schedule ID 0. This is probably a bug (chan_sip.c: do_dialog_unlink_sched_items, line 3266).
[2017-11-11 06:03:50] ERROR[5146] /builddir/build/BUILD/asterisk-13.17.2/include/asterisk/utils.h: Memory Allocation Failure in function ast_str_create at line 655 of /builddir/build/BUILD/asterisk-13.17.2/include/asterisk/strings.h
[2017-11-11 06:03:50] WARNING[5146] chan_sip.c: sip_xmit of 0x7f0428c3af80 (len 139655827686296) to 108.23.78.98:4279 returned -2: Cannot allocate memory
[2017-11-11 06:03:50] ERROR[5146] chan_sip.c: Serious Network Trouble; __sip_xmit returns error for pkt data
[2017-11-11 06:03:50] ERROR[5146] astobj2.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f04286eac38 (0)
Did you see the log I attached? Seems to have a lot more info around the FRACKs than previous ones, before BETTER_BACKTRACES was enabled. Do you see anything helpful there?
Particularly here:
[2017-11-11 06:03:50] ERROR[5146] /builddir/build/BUILD/asterisk-13.17.2/include/asterisk/utils.h: Memory Allocation Failure in function ast_str_create at line 655 of /builddir/build/BUILD/asterisk-13.17.2/include/asterisk/strings.h