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
       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.