Provided by: kopano-server_8.7.0-7.1ubuntu11_amd64
kopano-coredump — Coredump generation settings
Coredump generation is largely controlled by the surrounding operating system. Kopano daemons only have little control over it (see end of this document).
Location for dumps Ensure that the kernel.core_pattern sysctl specifies a template which is writable for the (unprivileged) daemon process. If the template is left at the default value ("core") and the working directory of the daemon, controlled with the "running_path" directive in the config file, happens to be an unwritable directory such as the root directory, a dump cannot be generated. If in doubt, set kernel.core_pattern to something like /tmp/core.%E.%p, which produces standard uncompressed ELF cores. Ensure enough disk space is available. You should compress it before sending it to Kopano. sysctls may not necessarily be settable from within a Linux container, in which case this has to be done in the top namespace. 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: The user shell limits are defined in /etc/security/limits.conf and often need to be adjusted, such as by adding a line like: * hard core 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 automatic generation as explained above does not work for whatever reason (such as the inability to edit kernel.core_pattern). Using gdb, one can attach to a particular process or start a new instance, and then inspect its state. Generate dumpfile 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" a few times.