kopano-coredump(5)

💖 kopano-coredump 💖

okay bestie, so this is kopano-coredump(5) from the Kopano Core user reference — it's the whole tea on coredump generation settings. sit with me, we're doing this. 🫶

---

✨ Name ✨

kopano-coredump — coredump generation settings 🌸

---

✨ Description ✨

ngl, whether you get a coredump is mostly in the hands of the surrounding operating system, not Kopano. the Kopano daemons lowkey barely have any control over it (there's a lil bit at the end of this doc, keep reading 💅).

---

✨ System configuration ✨

🎀 Location for dumps 🎀

first vibe check: make sure the kernel.core_pattern sysctl points at a template that's writable for the (unprivileged) daemon process. like, actually writable.

here's the trap: if that template is left at its default value, "core", and the daemon's working directory — the one controlled by the "running_path" directive in the config file — happens to be somewhere unwritable like the root directory, then a dump cannot be generated. no dump. none. 😭

so if you're in doubt, set kernel.core_pattern to something like /tmp/core.%E.%p, which produces standard uncompressed ELF cores. make sure there's enough disk space too — this stuff adds up. and before you send it to Kopano, compress it. 💖

heads up: sysctls may not necessarily be settable from within a Linux container 🫠 if that's you, this has to be done in the top namespace.

🎀 Applicable limits 🎀

depends on how you're starting the thing, so buckle up:

• when you start the service via systemd/systemctl: the coredump size limit is by default infinite. you can define a global coredump limit in /etc/systemd/system.conf, so just make sure no custom value has been set (cf. the "DefaultLimitCORE" directive).
• to check a particular service's current applied policy, you can also run systemctl show kopano-server and look at the LimitCORE= directive. 👀
• alternatively, when starting the program directly from a shell prompt without any service manager: the user shell limits live in /etc/security/limits.conf and often need adjusting, like by adding a line like:

* hard core unlimited

---

✨ Kopano service settings ✨

so once the system is all set up for core generation, there's one more option on the Kopano side. just one. iconic restraint tbh.

• 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 it's otherwise permitted by the system.
• when coredump_enabled=systemdefault, the system configuration is used as is. no notes. 💅
• 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's an alternate way of generating dumps using gdb, and it's genuinely a lifesaver if the automatic generation explained above doesn't work for whatever reason (like, say, you can't edit kernel.core_pattern). 🙈

with gdb you can attach to a particular process or start a new instance, and then inspect its state. main character energy.

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

also bestie: 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. not a bug, just the vibe. 💀

---

and that's the whole page, bestie. this was Kopano 8, dated 2017-09, and it's the kopano-coredump(5) manpage — now go forth and dump cores responsibly. 💜✨🎀