Documentation

Documentation.TroubleShooting-Crash History

Hide minor edits - Show changes to markup

December 08, 2023, at 05:28 PM by liviu -
Changed lines 67-68 from:

Extracting a back trace from the core file

to:

Extracting a back trace from the core file

December 08, 2023, at 05:27 PM by liviu -
Changed lines 36-37 from:

How to make sure OpenSIPS dumps a proper core file

to:

How to make sure OpenSIPS dumps a proper core file

December 08, 2023, at 05:26 PM by liviu -
Changed line 44 from:

2. Make sure your OS does not have special handling for the corefiles which might have them moved/deleted, e.g. through the "apport" suite:

to:

2. Avoid undesired special handling for the corefiles which might have them moved/deleted by default, e.g. by the "apport" suite:

December 08, 2023, at 05:26 PM by liviu -
Changed lines 44-46 from:

2. Before starting OpenSIPS, make sure to run 'ulimit -c unlimited' . This tells the system to allow OpenSIPS to dump a core file of unlimited size. This is useful, because in case of a crash, the core file will be at least the size of your shared memory + private memory. The ulimit commands usually should go in your init.d script for OpenSIPS

3. If you are running OpenSIPS with a different username and group ( -u and -g params ), some kernels might need some extra configuration to allow core dumps :

to:

2. Make sure your OS does not have special handling for the corefiles which might have them moved/deleted, e.g. through the "apport" suite:

$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E 

# to disable piping the corefiles to "apport", simply do:
$ echo "core.%p" > /proc/sys/kernel/core_pattern

3. Before starting OpenSIPS, make sure to run 'ulimit -c unlimited' . This tells the system to allow OpenSIPS to dump a core file of unlimited size. This is useful, because in case of a crash, the core file will be at least the size of your shared memory + private memory. The ulimit commands usually should go in your init.d script for OpenSIPS

4. If you are running OpenSIPS with a different username and group ( -u and -g params ), some kernels might need some extra configuration to allow core dumps :

Changed line 59 from:

4. Make sure your core files do not get overwritten. There are several sysctl options that can be used for this :

to:

5. Make sure your core files do not get overwritten. There are several sysctl options that can be used for this :

October 26, 2021, at 11:29 AM by liviu -
Changed line 67 from:

gdb /usr/local/sbin/opensips core.6645

to:

gdb /usr/sbin/opensips core.6645

June 06, 2016, at 08:32 PM by liviu -
Changed line 64 from:

Corefiles will usually be named "core" or "core.pid", and placed in the working OpenSIPS directory ("-w" command-line parameter). gdb can interpret them:

to:

Corefiles will usually be named "core" or "core.<pid>", and placed in the working OpenSIPS directory ("-w" command-line parameter). gdb can interpret them:

June 06, 2016, at 08:31 PM by liviu -
Changed line 64 from:

Corefiles will usually be named "core", and placed in the working OpenSIPS directory ("-w" command-line parameter). gdb can interpret them:

to:

Corefiles will usually be named "core" or "core.pid", and placed in the working OpenSIPS directory ("-w" command-line parameter). gdb can interpret them:

June 06, 2016, at 08:31 PM by liviu -
Changed line 80 from:

The core file on its own is useless without the exact OpenSIPS binary and modules directory that lead to the crash.

to:

The core file on its own is useless without the exact OpenSIPS binary and modules directory (".so" module libraries) that lead to the crash.

June 06, 2016, at 08:30 PM by liviu -
Changed lines 78-80 from:

Do not delete the core file and also make sure to keep an exact copy of your OpenSIPS binary, as the OpenSIPS developers might need to extra more information from the core file, like printing various variables, etc. The core file on it's own is useless without the exact OpenSIPS binary file that lead to the crash.

to:

Do not delete the core file and also make sure to keep an exact copy of your OpenSIPS binary, as the OpenSIPS developers might need to extra more information from the core file, like printing various variables, etc.

The core file on its own is useless without the exact OpenSIPS binary and modules directory that lead to the crash.

June 06, 2016, at 08:29 PM by liviu -
Changed line 64 from:

Corefiles will usually be named "core", and placed in the working OpenSIPS directory ("-w" binary parameter). gdb can interpret them:

to:

Corefiles will usually be named "core", and placed in the working OpenSIPS directory ("-w" command-line parameter). gdb can interpret them:

June 06, 2016, at 08:28 PM by liviu -
Changed line 64 from:

Corefiles will usually be named "core", and placed in the working OpenSIPS directory ("-w" cmdline parameter). gdb can interpret them:

to:

Corefiles will usually be named "core", and placed in the working OpenSIPS directory ("-w" binary parameter). gdb can interpret them:

June 06, 2016, at 08:27 PM by liviu -
Changed lines 58-59 from:

Browse the logs for the

to:

Browse the logs for a "signal 11" notification from one of the OpenSIPS workers. This means that it has crashed (invalid memory access):

Changed line 64 from:

and the run

to:

Corefiles will usually be named "core", and placed in the working OpenSIPS directory ("-w" cmdline parameter). gdb can interpret them:

June 06, 2016, at 08:23 PM by liviu -
Changed line 67 from:

gdb /usr/sbin/opensips core.6645

to:

gdb /usr/local/sbin/opensips core.6645

June 06, 2016, at 08:23 PM by liviu -
Changed line 67 from:

gdb opensips core.6645

to:

gdb /usr/sbin/opensips core.6645


Page last modified on December 08, 2023, at 05:28 PM