Asterisk 18.3.0 suddenly crashed

Hello!
We have 4 servers with Asterisk 18.3.0 for inbound calls.
Sometimes this Asterisk will suddenly crashed.
In dmesg I see.
[17423.018715] traps: asterisk[75352] general protection fault ip:7f6083a848c7 sp:7f5fcf52e838 error:0 in libc-2.28.so[7f6083927000+1b9000]
Can you help me to find reason of this? What to watch to find the reason?
In asterisk logs I don’t see any error messages.

You’d have to get a backtrace[1].

[1] Getting a Backtrace - Asterisk Project - Asterisk Project Wiki

When I try to run sudo /var/lib/asterisk/scripts/ast_coredumper core
I have
No coredumps found
I was checked twice all recommendations from instruction, but result the same
Asterisk running with -g option
]$ ps -C asterisk u
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
asterisk 8989 0.4 1.1 2999284 70308 ? Sl 15:35 0:14 /usr/sbin/asterisk -f -vvvg -c

What distribution are you using? When did it last crash?

We use RHEL8. Last crash occurs about 3 hours ago

I’m not that familiar with where RHEL would store the core dumps unfortunately.

RHEL 8 uses systemd. Like RHEL 7 and CentOS. Systemd comes with coredumpctl. If it’s activated, you get all coredumps with

coredumpctl list

On Redhat site, you get for sure a lot of information about coredumpctl. If there is no coredump, you may especially take a look here.

All systems store them in the current working directory. What that is, in the case of Asterisk, is normally determined by the startup script, which will be the same as that for Centos, assuming that one uses the ones that come with the Asterisk sources. That will run Asterisk with /tmp as current directory, and, will also use safe_asterisk, which will rename the files, to include the date, but also leave them in /tmp.

Note that some distributions clear out /tmp on a reboot, so you may need to capture the core files before then. Also you will fail to get a core file if there is not enough space on /tmp.

Without a core file, the only ways of making progress are to run Asterisk under gdb, or to turn up the logging and try to work out what was going on before the crash.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.