{"id":1354,"date":"2026-10-10T22:02:23","date_gmt":"2026-10-10T22:02:23","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1354"},"modified":"2026-10-10T22:02:23","modified_gmt":"2026-10-10T22:02:23","slug":"systemd-coredump-core-dump-analysis-vps-crash-debugging","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/","title":{"rendered":"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">When a service dies on a small VPS you usually get &#8220;status=11\/SEGV&#8221; and nothing else. The crash dump that would tell you exactly which instruction faulted and on what address is almost always already captured by <code>systemd-coredump<\/code> &#8212; it is just never opened. This walkthrough sets up core capture correctly and then reads the stack trace out of it, turning an opaque restart loop into a specific bug you can fix.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This is written for a <a href=\"https:\/\/virtualserversvps.com\/\">memory-constrained VPS where unbounded core files could fill the disk<\/a>, so every step includes the guard rails. The same debugging discipline applies to any workload you run on the <a href=\"https:\/\/virtualserversvps.com\/\">hosting platform<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Why you probably see no core file<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Three independent things can suppress a core dump, and missing any one means silence:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ulimit -c                       # must be non-zero for the process\ncat \/proc\/sys\/kernel\/core_pattern\nsystemctl show myapp.service -p LimitCORE<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">On Debian\/Ubuntu, <code>core_pattern<\/code> is typically <code>|\/lib\/systemd\/systemd-coredump %P %u %g %s %t %c %h<\/code> &#8212; the leading pipe means cores are piped to the coredump helper rather than written as a file. That is fine, but only if <code>systemd-coredump<\/code> is installed and the process&#8217;s <code>LimitCORE<\/code> is not zero. A hardened unit with <code>LimitCORE=0<\/code> (a common hardening copy-paste) guarantees you never get a dump.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Setting it up without filling the disk<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>apt-get install -y systemd-coredump\ncat &lt;&lt;'EOF' &gt; \/etc\/systemd\/coredump.conf\n[Coredump]\nStorage=external\nCompress=yes\nProcessSizeMax=2G\nExternalSizeMax=1G\nMaxUse=200M\nKeepFree=1G\nEOF\nsystemctl restart systemd-coredump.socket<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><code>MaxUse=200M<\/code> and <code>KeepFree=1G<\/code> are the important guard rails on a small box: cores are compressed and old ones are pruned automatically, so a crash loop cannot exhaust storage. <code>ExternalSizeMax=1G<\/code> caps any single dump. Verify the effective settings with <code>coredumpctl --help<\/code> won&#8217;t show them &#8212; use <code>systemd-analyze cat-config systemd\/coredump.conf<\/code> instead.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Then make sure your unit keeps its dump policy sane. Remove <code>LimitCORE=0<\/code> if it is present, or set it explicitly:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[Service]\nLimitCORE=infinity<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Listing and inspecting dumps<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>coredumpctl list --since \"-2h\"\ncoredumpctl info myapp.service<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><code>coredumpctl info<\/code> prints the signal, fault address, command line, and environment of the crash without extracting anything. The <code>Message<\/code> field distinguishes &#8220;Segmentation fault&#8221; (bad memory access) from &#8220;Assertion failed&#8221; (a deliberate <code>abort()<\/code>) &#8212; assert crashes need no stack inspection, the message already names the failed invariant.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Getting a real backtrace<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Symbolised backtraces require the binary and, for interpreted or JIT workloads, the interpreter. Install debug symbols first, otherwise frames are addresses with no names.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>coredumpctl gdb myapp.service &lt;&lt;'EOF'\nset pagination off\nthread apply all bt full\ninfo registers\nx\/4i $pc-8\ninfo proc mappings\nquit\nEOF<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The three commands that matter most: <code>bt full<\/code> shows the call stack with local variables, <code>info registers<\/code> plus <code>x\/4i $pc-8<\/code> disassembles around the program counter showing exactly which instruction faulted, and <code>info proc mappings<\/code> tells you whether the fault address was inside a mapped region &#8212; a fault on an obvious mapped address means a use-after-free or buffer overflow, while a fault on an unmapped address usually means a wild pointer or stack overflow.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Debug symbols without bloating the box<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>echo \"deb http:\/\/deb.debian.org\/debian-debug bookworm-debug main\" \\\n  &gt; \/etc\/apt\/sources.list.d\/debug.list\napt-get update\napt-get install -y systemd-coredump-dbgsym\n# install the specific binary's symbols, not the whole debug repo\ndebuginfod-find debuginfo \/usr\/sbin\/myapp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Debug packages are large, so install only the symbol package for the crashing binary and remove it afterwards. <code>debuginfod<\/code> can fetch symbols on demand, but on a metered VPS it is worth controlling the traffic by installing explicitly rather than letting gdb pull them automatically.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Reading the story in a stack trace<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A few patterns cover most crash classes:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Frame ends in <code>__memcpy<\/code> or <code>__strlen<\/code> with a garbage source pointer: buffer overflow or a freed pointer being read.<\/li><li>Recursion repeated hundreds of frames ending in <code>SIGSEGV<\/code>: stack overflow &#8212; raise <code>LimitSTACK<\/code> for a stopgap and fix the recursion for real.<\/li><li>Frame in <code>malloc<\/code> or <code>free<\/code> with a corrupted heap: double-free, and <code>MALLOC_CHECK_=3<\/code> or linking against <code>libasan<\/code> will localise it faster than stack reading.<\/li><li>Crash only under <code>LimitAS<\/code> or cgroup memory caps: an allocation failure that the code did not check &#8212; grep the source for unchecked <code>malloc<\/code>.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Automating post-crash capture<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A crash that auto-restarts loses its context once the unit is back up if you do nothing. Extract a summary automatically so it survives restarts:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[Service]\nOnFailure=core-report@%n.service\n\n# core-report@.service\n[Service]\nType=oneshot\nExecStart=\/usr\/local\/bin\/core-report.sh %i<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>#!\/bin\/bash\n# \/usr\/local\/bin\/core-report.sh\nsvc=\"$1\"\nout=\"\/var\/log\/crash-$(date +%s)-$svc.txt\"\ncoredumpctl info \"$svc\" &gt; \"$out\"\ncoredumpctl gdb \"$svc\" &lt;&lt;'EOF' 2&gt;&gt; \"$out\"\nset pagination off\nthread apply all bt\nquit\nEOF\nlogger -t core-report \"captured $out\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">With <code>OnFailure=<\/code> wired up, any crash leaves a text report with a backtrace behind, so you can debug a service that crashes at 3 a.m. without having to reproduce it. Keep the reports pruned with logrotate and you have a self-maintaining crash forensics pipeline on a box with no external tooling.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>When a service dies on a small VPS you usually get &#8220;status=11\/SEGV&#8221; and nothing else. The crash dump that would tell you exactly which instruction faulted and on what address&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":2,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1354","post","type-post","status-publish","format-standard","hentry","category-vps-guides-tutorials"],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v26.1 (Yoast SEO v26.1) - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow - Virtual Servers VPS Blog<\/title>\n<meta name=\"description\" content=\"When a service dies on a small VPS you usually get &quot;status=11\/SEGV&quot; and nothing else. The crash dump that would tell you exactly which instruction faulted\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow\" \/>\n<meta property=\"og:description\" content=\"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow\" \/>\n<meta property=\"og:url\" content=\"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/\" \/>\n<meta property=\"og:site_name\" content=\"Virtual Servers VPS Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-10-10T22:02:23+00:00\" \/>\n<meta name=\"author\" content=\"Virtual-Servers-Vps-Editor\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Virtual-Servers-Vps-Editor\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"4 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/\",\"name\":\"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow - Virtual Servers VPS Blog\",\"isPartOf\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\"},\"datePublished\":\"2026-10-10T22:02:23+00:00\",\"author\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\"},\"description\":\"When a service dies on a small VPS you usually get \\\"status=11\/SEGV\\\" and nothing else. The crash dump that would tell you exactly which instruction faulted\",\"breadcrumb\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/virtualserversvps.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/\",\"name\":\"Virtual Servers VPS Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\",\"name\":\"Virtual-Servers-Vps-Editor\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"caption\":\"Virtual-Servers-Vps-Editor\"},\"sameAs\":[\"https:\/\/virtualserversvps.com\/blog\"],\"url\":\"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow - Virtual Servers VPS Blog","description":"When a service dies on a small VPS you usually get \"status=11\/SEGV\" and nothing else. The crash dump that would tell you exactly which instruction faulted","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/","og_locale":"en_US","og_type":"article","og_title":"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow","og_description":"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow","og_url":"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/","og_site_name":"Virtual Servers VPS Blog","article_published_time":"2026-10-10T22:02:23+00:00","author":"Virtual-Servers-Vps-Editor","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Virtual-Servers-Vps-Editor","Est. reading time":"4 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/","url":"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/","name":"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow - Virtual Servers VPS Blog","isPartOf":{"@id":"https:\/\/virtualserversvps.com\/blog\/#website"},"datePublished":"2026-10-10T22:02:23+00:00","author":{"@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0"},"description":"When a service dies on a small VPS you usually get \"status=11\/SEGV\" and nothing else. The crash dump that would tell you exactly which instruction faulted","breadcrumb":{"@id":"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/virtualserversvps.com\/blog\/systemd-coredump-core-dump-analysis-vps-crash-debugging\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/virtualserversvps.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Analyzing systemd-coredump Crash Dumps on a VPS: A Practical Debugging Workflow"}]},{"@type":"WebSite","@id":"https:\/\/virtualserversvps.com\/blog\/#website","url":"https:\/\/virtualserversvps.com\/blog\/","name":"Virtual Servers VPS Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0","name":"Virtual-Servers-Vps-Editor","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","caption":"Virtual-Servers-Vps-Editor"},"sameAs":["https:\/\/virtualserversvps.com\/blog"],"url":"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/"}]}},"_links":{"self":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1354","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/comments?post=1354"}],"version-history":[{"count":1,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1354\/revisions"}],"predecessor-version":[{"id":1356,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1354\/revisions\/1356"}],"wp:attachment":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/media?parent=1354"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/categories?post=1354"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/tags?post=1354"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}