OpenSIPS crashes

Goal

When OpenSIPS crashes, the most useful thing you can send to the developers is a bt full backtrace from the core dump, together with the OpenSIPS version and the relevant logs.

1. Check the logs

If OpenSIPS logs to syslog, check the usual system log files or the systemd journal:

sudo tail -f /var/log/syslog
sudo tail -f /var/log/messages
sudo journalctl -u opensips.service -f

In current OpenSIPS versions, logging to standard error and syslog is controlled with:

stderror_enabled = yes
syslog_enabled = no

Use this temporary setting if you want the logs printed in the console where OpenSIPS is running. Older OpenSIPS 3.x configurations may still use log_stderror; in OpenSIPS 4.0 and later, use stderror_enabled and syslog_enabled.

2. Confirm it was a crash

Look for a child process exiting due to a signal:

child process 6645 exited by a signal 11

Signal 11 usually means a segmentation fault. Signals such as signal 6 (SIGABRT) or signal 7 (SIGBUS) can also produce useful core dumps.

If you only see messages such as:

terminating due to SIGTERM

then OpenSIPS was probably stopped by an external action, not by a crash. Check the service manager, monitoring tools, container runtime, or kernel logs.

3. Find the core dump

First, check how the system handles core dumps:

cat /proc/sys/kernel/core_pattern

If the output starts with |, the core is handled by a helper.

For systemd-coredump, use:

coredumpctl list opensips
coredumpctl info <PID>
coredumpctl gdb <PID>

If the output does not start with |, the core is usually written in the OpenSIPS working directory, set with -w:

gdb /usr/sbin/opensips /path/to/core.<PID>

The binary path must match the binary that produced the core. Common paths are /usr/sbin/opensips or the local opensips binary from a source build.

4. If no core dump is generated

Enable core dumps before reproducing the crash.

For a manual start:

ulimit -c unlimited
opensips -w /var/lib/opensips

For a systemd service:

sudo systemctl edit opensips.service

Add:

[Service]
LimitCORE=infinity

Then restart OpenSIPS:

sudo systemctl restart opensips.service

If you want core files written directly to the OpenSIPS working directory:

sudo sysctl -w kernel.core_pattern='core.%e.%p.%t'
sudo sysctl -w kernel.core_uses_pid=1

If OpenSIPS starts as one user and then changes user or group with -u / -g, you may also need:

sudo sysctl -w fs.suid_dumpable=1

Core files may contain SIP credentials, database credentials, private keys, and message contents. Store them in a restricted directory and do not publish them publicly.

5. Running in Docker

For logs, start with:

docker logs <container>

For core dumps, remember that containers use the host kernel core-dump settings. Enable core dumps for the container and mount a directory where the core can be kept:

docker run \
  --ulimit core=-1 \
  -v /tmp/opensips-cores:/cores \
  <image> \
  opensips -w /cores

With Docker Compose:

services:
  opensips:
    ulimits:
      core: -1
    volumes:
      - /tmp/opensips-cores:/cores

If /proc/sys/kernel/core_pattern starts with |, look for the core on the host using the configured helper, for example coredumpctl. Otherwise, look in the mounted core directory.

Run gdb using the same image, binary, and modules that produced the core:

docker run --rm -it \
  -v /tmp/opensips-cores:/cores \
  <image> \
  gdb /usr/sbin/opensips /cores/core.<PID>

6. Extract the backtrace

Once inside gdb, run:

set pagination off
bt full
quit

If possible, install matching debug symbols before running gdb. If debug symbols are not available, still publish the backtrace; even a partial backtrace is better than no backtrace.

Keep the core file, the exact OpenSIPS binary, and the loaded module libraries (.so files). Developers may ask for them privately if the backtrace is not enough.

7. Report the crash

Send the report to the OpenSIPS GitHub issue tracker or to the devel@lists.opensips.org mailing list.

Include:

• the output of opensips -V
• the operating system and architecture
• the log lines around the crash
• the bt full output
• the relevant opensips.cfg parts, with secrets removed
• whether the full core file, binary, and modules can be provided privately