kopano-coredump(5)

Name

kopano-coredump — Coredump generation settings

Description

Coredump generation is largely controlled by the surrounding operating system. Kopano daemons only have little control over it (see end of this document).

System configuration

  Location for dumps

The kernel.core_pattern sysctl specifies a filename template to use for dumps, or a pipe command. For details on the pipe mechanism, see core(5).

sysctls may not necessarily be settable from within a Linux container, in which case this has to be done in the top namespace. In absence of that ability, see the gdb attach method below.

The use of a piped command is discouraged somewhat, because the utilities such as abrt(1) or apport(1) are only available on the one platform they are used on, and in essence generate non-standard archives that are difficult to unpack elsewhere.

Because processes may change their working directory to the root directory which is unwritable for them, the core_pattern should specify a template with an absolute path to a writable directory, e.g. /tmp/core.%E.%p.

Using a filename template generates a normal, uncompressed ELF dump. The file will be as big as the memory used by the process at the time, so it makes sense to compress it (zstd, xz) before transmission to the developers.

  Applicable limits

When starting the service via systemd/systemctl: The coredump size limit is by default infinite. It is possible to define a global coredump limit in /etc/systemd/system.conf, so ensure that no custom value (cf. "DefaultLimitCORE" directive) has been set.

To check for a particular service's current applied policy, you can also use: `systemctl show kopano-server` and look at the LimitCORE= directive.

Alternatively, when starting the program directly from a shell prompt without the use of a service manager, two things need to be checked. First, the default limits for login shells is defined in /etc/security/limits.conf and may need to be adjusted, such as by adding this 4-column line:

	* hard core unlimited

With that, (newly-created) login shells can raise the soft limit as the situation needs, by using `ulimit -c unlimited`.

Kopano service settings

Once the system is set up for core generation, there is one more option on the kopano side.

•   kopano-dagent, kopano-gateway and kopano-spooler offer a "coredump_enabled" directive in their configuration file, and its default value is "systemdefault".

•   kopano-server has a "coredump_enabled" directive as well, and it defaults to "yes".

All other daemons which recognize no such directive in their config file behave as if coredump_enabled=systemdefault was in effect.

•   When coredump_enabled=no, the daemon sets the maximum core size to zero, which effectively deactivates dump generation even if otherwise permitted by the system.

•   When coredump_enabled=systemdefault, the system configuration is used as is.

•   When coredump_enabled=yes, the daemon attempts to increase the inherited system default value for itself to infinity. This is only really necessary if the system defaults (LimitNCORE, see above) specify a low limit.

Dump generation via gdb

There is an alternate way of generating dumps, using gdb, which is helpful if the kernel-based generation as set up by way of the sysctl does not work for whatever reason (such as the inability to edit kernel.core_pattern), or when the shell limits cannot be raised.

Using gdb, one can attach to a particular process, or start a new instance, and then inspect its state.

  Generate dumpfile

(gdb) run Thread 1 "kopano-dagent" received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) gcore warning: target file /proc/25097/cmdline contained unexpected null characters Saved corefile core.25097

  Backtrace

A backtrace produced by gdb is usually a higher quality than the one produced by the process itself. For this, the debuginfo must be available in the system. (When running a version built yourself, the info is inside the executable. (When running a version from prebuilt binaries, look for package names containing "debug", "dbg" or similar.)

(gdb) thread apply all bt

  Signal interruptions

Some signals are received under normal conditions, such as SIGPIPE. To have gdb not stop and require user input all the time, SIGPIPE should be ignored:

(gdb) handle SIGPIPE nostop noprint
If you expect to observe a process for a really long time, it may make sense to do the same for SIGHUP too.

Note that openssl will, on certain architectures (ARM, PPC, s390x, sparcv9), use "smoke testing" to determine CPU capabilities, where it issues CPU instructions that not all CPUs understand. openssl sets up a signal handler to deal with it, but said signals will still stop gdb and you need to issue "continue" (or "c") a few times.