kopano-core/doc/coredump.txt

To enable coredumps:

* coredump_enabled=yes needs to be set in the configuration file
  of the particular kopano daemon.

* If the daemon in question is configured to switch to another user
  user (cf. "run_as_user" and "run_as_group" configuration file
  directives), the fs.suid_dumpable sysctl needs to be changed. See
  the procfs(5) manual page for more information.
  When setting fs.suid_dumpable=2, kernel.core_pattern *must not*
  be a relative path.

* 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 (cf. /proc/N/cwd) happens to be an unwritable directory such
  as the root directory (cf. "running_path" directive in
  configuration file), a dump cannot be generated.

* sysctls may not necessarily be settable from within a Linux
  container, in which case this has to be done in the top namespace.

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

* 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 "* hard core unlimted" (no quotes) line.

* When starting the service in a sysvinit environment:
  (it's a mess).

  Executing /etc/init.d/kopano-server from a shell follows the
  "Shell prompt" limitation above.

  When letting the service be started by the runlevel scripts:
  Possibly no limits apply.