add some bits about linux coredumps

README_maintainers.md

@@ -342,9 +342,21 @@ arangod commandline arguments
 
 __________________________________________________________________________________________________________
 
-Linux Cordeumps
+Linux Coredumps
 ===============
-Hint: on Ubuntu the `apport` package may interfere with this.
+Generally coredumps have to be enabled using:
+
+     ulimit -c unlimited
+
+You should then see:
+
+     ulimit -a
+     core file size          (blocks, -c) unlimited
+
+for each shell and its subsequent processes.
+
+Hint: on Ubuntu the `apport` package may interfere with this; however you may use the `systemd-coredump` package
+which automates much of the following:
 
 So that the unit testing framework can autorun gdb it needs to reliably find the corefiles.
 In Linux this is configured via the `/proc` filesystem, you can make this reboot permanent by
@@ -365,6 +377,22 @@ Solaris Coredumps
 Solaris configures the system corefile behaviour via the `coreadm` programm.
 see https://docs.oracle.com/cd/E19455-01/805-7229/6j6q8svhr/ for more details.
 
+Analyzing Coredumps on Linux
+============================
+We offer debug packages containing the debug symbols for your binaries. Please install them if you didn't compile yourselves.
+
+Given you saw in the log of the arangod with the PID `25216` that it died, you should then find 
+`/var/tmp/core-V8 WorkerThread-25216-1490887259` with this information. We may now start GDB and inspect whats going on:
+
+    gdb /usr/sbin/arangod /var/tmp/*25216*
+
+These commands give usefull information about the incident:
+
+    backtrace full
+    thread apply all bt
+
+The first gives the full stacktrace including variables of the last active thread, the later one the stacktraces of all threads.
+
 Windows debugging
 =================
 For the average \*nix user windows debugging has some awkward methods.