coredump,catalog: give better notice when a core file is truncated

coredump had code to check if copy_bytes() hit the max_bytes limit,
and refuse further processing in that case.
But in 84ee0960443, the return convention for copy_bytes() was changed
from -EFBIG to 1 for the case when the limit is hit, so the condition
check in coredump couldn't ever trigger.
But it seems that *do* want to process such truncated cores [1].
So change the code to detect truncation properly, but instead of
returning an error, give a nice log entry.

[1] https://github.com/systemd/systemd/issues/3883#issuecomment-239106337

Should fix (or at least alleviate) #3883.

1 files changed, 11 insertions, 0 deletions

diff --git a/catalog/systemd.catalog.in b/catalog/systemd.catalog.in
index 8de8597fe9..2c72d31290 100644
--- a/catalog/systemd.catalog.in
+++ b/catalog/systemd.catalog.in
@@ -88,6 +88,17 @@ Process @COREDUMP_PID@ (@COREDUMP_COMM@) crashed and dumped core.
 This usually indicates a programming error in the crashing program and
 should be reported to its vendor as a bug.
 
+-- 5aadd8e954dc4b1a8c954d63fd9e1137
+Subject: Core file was truncated to @SIZE_LIMIT@ bytes.
+Defined-By: systemd
+Support: %SUPPORT_URL%
+Documentation: man:coredump.conf(5)
+
+The process had more memory mapped than the configured maximum for processing
+and storage by systemd-coredump(8). Only the first @SIZE_LIMIT@ bytes were
+saved. This core might still be usable, but various tools like gdb(1) will warn
+about the file being truncated.
+
 -- fc2e22bc6ee647b6b90729ab34a250b1 de
 Subject: Speicherabbild für Prozess @COREDUMP_PID@ (@COREDUMP_COMM) generiert
 Defined-By: systemd