This cleans up and unifies the outut of --help texts a bit:
1. Highlight the human friendly description string, not the command
line via ANSI sequences. Previously both this description string and
the brief command line summary was marked with the same ANSI
highlight sequence, but given we auto-page to less and less does not
honour multi-line highlights only the command line summary was
affectively highlighted. Rationale: for highlighting the description
instead of the command line: the command line summary is relatively
boring, and mostly the same for out tools, the description on the
other hand is pregnant, important and captions the whole thing and
hence deserves highlighting.
2. Always suffix "Options" with ":" in the help text
3. Rename "Flags" → "Options" in one case
4. Move commands to the top in a few cases
5. add coloring to many more help pages
6. Unify on COMMAND instead of {COMMAND} in the command line summary.
Some tools did it one way, others the other way. I am not sure what
precisely {} is supposed to mean, that uppercasing doesn't, hence
let's simplify and stick to the {}-less syntax
And minor other tweaks.
For executables which take a verb, we should list the verbs first, and
then options which modify those verbs second. The general layout of
the man page is from general description to specific details, usually
Overview, Commands, Options, Return Value, Examples, References.
Now we first gather all process metadata and populate the process info cache
with them. In this way, the cache only references metadata recorded in iovecs[]
so there's no need to bother freeing (part of) cached metadata later.
The other advantage is that the coredump handler mode and the service mode are
more similar as the cache is populated in the same way for both cases.
It also renames the array indexes so it becomes clear which metadata are passed
by the kernel and which ones are retrieved from the runtime environment.
'input_fd' variable name is used mostly everywhere except in process_socket()
where it's named 'coredump_fd', which is pretty confusing since 'coredump_fd'
is used for the coredump filename in submit_coredump().
So let's use 'input_fd' consistently as name for the pipe fd passed by the
kernel.
No functional changes.
Previous code was allocating an array of iovecs big enough to store all the
fields added later by various functions.
This forced us to calculate the size of the array in advance which is too error
prone if for example one wants to add new fields or simply rework the
code. Various assertions were added to make sure there's no overflow but it's
still more code for no good reasons.
Instead, this patch switches to the new iovec array handling interface so the
array is grown dynamically when needed.
The other contraint was that some iovecs were supposed to be freed whereas some
others were not. This makes the code hard to (re)organize. The new code always
allocates fields so it becomes easier to rework the code.
I couldn't see any reason why the kernel could provide COMM to the coredump
handler via the core_pattern command line but could not make it available in
/proc. So let's assume that this info is always available in /proc.
For "backtrace" mode (when --backtrace option is passed), I assumed that the
crashing process still exists at the time systemd-coredump is called.
Also changing the core_pattern line is an API breakage for any users of the
backtrace mode but given that systemd-coredump is installed in
/usr/lib/systemd, it's a private tool which has no internal users. At least no
one complained when the hostname was added to the core_pattern line
(f45b801551)...
Indeed it's much easier to get it from /proc since the kernel substitutes '%e'
specifier with multiple strings if the process name contains spaces (!).
The functions to retrieve and print process cmdlines were based on the
assumption that they contain printable ASCII, and everything else
should be filtered out. That assumption doesn't hold in today's world,
where people are free to use unicode everywhere.
This replaces the custom cmdline reading code with a more generic approach
using utf8_escape_non_printable_full().
For kernel threads, truncation is done on the parenthesized name, so we'll
get "[worker]", "[worker…]", …, "[w…]", "[…", "…" as we reduce the number of
available columns.
This implementation is most likely slower for very long cmdlines, but I don't
think this is very important. The common case is to have short commandlines,
and should print those properly. Absurdly long cmdlines are the exception,
which needs to be handled correctly and safely, but speed is not too important.
Fixes#12532.
v2:
- use size_t for the number of columns. This change propagates into various
other functions that call get_process_cmdline(), increasing the size of the
patch, but the changes are rather trivial.
When emitting the calendarspec warning we want to see some color.
Follow-up for 04220fda5c.
Exceptions:
- systemctl, because it has a lot hand-crafted coloring
- tmpfiles, sysusers, stdio-bridge, etc, because they are also used in
services and I'm not sure if this wouldn't mess up something.
Let's be helpful to static analyzers which care about whether we
knowingly ignore return values. We do in these cases, since they are
usually part of error paths.
If creation of the message failed, we'd write a bogus entry:
systemd-coredump[1400]: Cannot store coredump of 416 (systemd-journal): No space left on device
systemd-coredump[1400]: MESSAGE=Process 416 (systemd-journal) of user 0 dumped core.
systemd-coredump[1400]: Coredump diverted to
This fixes a crash where we would read the commandline, whose length is under
control of the sending program, and then crash when trying to create a stack
allocation for it.
CVE-2018-16864
https://bugzilla.redhat.com/show_bug.cgi?id=1653855
The message actually doesn't get written to disk, because
journal_file_append_entry() returns -E2BIG.
systemd-coredump[9982]: MESSAGE=Process 771 (systemd-journal) of user 0 dumped core.
systemd-coredump[9982]: Coredump diverted to /var/lib/systemd/coredump/core...
log_dispatch() calls log_dispatch_internal() which calls write_to_journal()
which appends MESSAGE= on its own.
fdopen doesn't accept "e", it's ignored. Let's not mislead people into
believing that it actually sets O_CLOEXEC.
From `man 3 fdopen`:
> e (since glibc 2.7):
> Open the file with the O_CLOEXEC flag. See open(2) for more information. This flag is ignored for fdopen()
As mentioned by @jlebon in #11131.
This splits out a bunch of functions from fileio.c that have to do with
temporary files. Simply to make the header files a bit shorter, and to
group things more nicely.
No code changes, just some rearranging of source files.
Similar to the previous commit: in many cases no further fd processing
needs to be done in forked of children before execve() or any of its
flavours are called. In those case we can use FORK_RLIMIT_NOFILE_SAFE
instead.
Ideally, coccinelle would strip unnecessary braces too. But I do not see any
option in coccinelle for this, so instead, I edited the patch text using
search&replace to remove the braces. Unfortunately this is not fully automatic,
in particular it didn't deal well with if-else-if-else blocks and ifdefs, so
there is an increased likelikehood be some bugs in such spots.
I also removed part of the patch that coccinelle generated for udev, where we
returns -1 for failure. This should be fixed independently.
$ valgrind --show-leak-kinds=all --leak-check=full build/coredumpctl dump --output /tmp/ff
...
==16431== HEAP SUMMARY:
==16431== in use at exit: 3,680 bytes in 13 blocks
==16431== total heap usage: 831 allocs, 818 frees, 197,776 bytes allocated
==16431==
==16431== 2 bytes in 1 blocks are still reachable in loss record 1 of 13
==16431== at 0x483880B: malloc (vg_replace_malloc.c:299)
==16431== by 0x4C4D5AD: strdup (strdup.c:42)
==16431== by 0x49B2387: bus_message_parse_fields (bus-message.c:5300)
==16431== by 0x49A23AF: bus_message_from_malloc (bus-message.c:560)
==16431== by 0x49C459B: bus_socket_make_message (bus-socket.c:1099)
==16431== by 0x49C4C5B: bus_socket_read_message (bus-socket.c:1213)
==16431== by 0x49CE4CE: bus_read_message (sd-bus.c:1777)
==16431== by 0x49CFA2C: sd_bus_call (sd-bus.c:2176)
==16431== by 0x1105F3: check_units_active (coredumpctl.c:1029)
==16431== by 0x110998: run (coredumpctl.c:1087)
==16431== by 0x110A45: main (coredumpctl.c:1100)
==16431==
==16431== 9 bytes in 1 blocks are still reachable in loss record 2 of 13
==16431== at 0x483880B: malloc (vg_replace_malloc.c:299)
==16431== by 0x4939067: malloc_multiply (alloc-util.h:78)
==16431== by 0x493921D: hexmem (hexdecoct.c:62)
==16431== by 0x49C2B75: bus_socket_start_auth_client (bus-socket.c:626)
==16431== by 0x49C2D78: bus_socket_start_auth (bus-socket.c:665)
==16431== by 0x49C3B09: bus_socket_connect (bus-socket.c:915)
==16431== by 0x49CBB08: bus_start_address (sd-bus.c:1103)
==16431== by 0x49CBFEA: sd_bus_start (sd-bus.c:1187)
==16431== by 0x49CC452: sd_bus_open_system_with_description (sd-bus.c:1294)
==16431== by 0x49CC4C6: sd_bus_open_system (sd-bus.c:1303)
==16431== by 0x49D4424: bus_default (sd-bus.c:3655)
==16431== by 0x49D44BC: sd_bus_default_system (sd-bus.c:3668)
==16431==
==16431== 9 bytes in 1 blocks are still reachable in loss record 3 of 13
==16431== at 0x483880B: malloc (vg_replace_malloc.c:299)
==16431== by 0x4C4D5AD: strdup (strdup.c:42)
==16431== by 0x497364E: free_and_strdup (string-util.c:1013)
==16431== by 0x49C9FB1: hello_callback (sd-bus.c:547)
==16431== by 0x49D0A3A: process_reply (sd-bus.c:2498)
==16431== by 0x49D13E0: process_message (sd-bus.c:2677)
==16431== by 0x49D165F: process_running (sd-bus.c:2739)
==16431== by 0x49D20DD: bus_process_internal (sd-bus.c:2957)
==16431== by 0x49D21E8: sd_bus_process (sd-bus.c:2984)
==16431== by 0x49CF21E: bus_ensure_running (sd-bus.c:2053)
==16431== by 0x49CF51F: sd_bus_call (sd-bus.c:2095)
==16431== by 0x1105F3: check_units_active (coredumpctl.c:1029)
==16431==
==16431== 24 bytes in 1 blocks are still reachable in loss record 4 of 13
==16431== at 0x483880B: malloc (vg_replace_malloc.c:299)
==16431== by 0x495CB0D: malloc_multiply (alloc-util.h:78)
==16431== by 0x495CB2A: prioq_new (prioq.c:35)
==16431== by 0x495CC02: prioq_ensure_allocated (prioq.c:60)
==16431== by 0x49CEF84: sd_bus_call_async (sd-bus.c:1995)
==16431== by 0x49CA0E6: bus_send_hello (sd-bus.c:581)
==16431== by 0x49CC019: sd_bus_start (sd-bus.c:1196)
==16431== by 0x49CC452: sd_bus_open_system_with_description (sd-bus.c:1294)
==16431== by 0x49CC4C6: sd_bus_open_system (sd-bus.c:1303)
==16431== by 0x49D4424: bus_default (sd-bus.c:3655)
==16431== by 0x49D44BC: sd_bus_default_system (sd-bus.c:3668)
==16431== by 0x110444: check_units_active (coredumpctl.c:1007)
==16431==
==16431== 38 bytes in 1 blocks are still reachable in loss record 5 of 13
==16431== at 0x483880B: malloc (vg_replace_malloc.c:299)
==16431== by 0x4C4D5AD: strdup (strdup.c:42)
==16431== by 0x497364E: free_and_strdup (string-util.c:1013)
==16431== by 0x49C7F97: sd_bus_set_address (sd-bus.c:269)
==16431== by 0x49CC314: bus_set_address_system (sd-bus.c:1262)
==16431== by 0x49CC3E0: sd_bus_open_system_with_description (sd-bus.c:1281)
==16431== by 0x49CC4C6: sd_bus_open_system (sd-bus.c:1303)
==16431== by 0x49D4424: bus_default (sd-bus.c:3655)
==16431== by 0x49D44BC: sd_bus_default_system (sd-bus.c:3668)
==16431== by 0x110444: check_units_active (coredumpctl.c:1007)
==16431== by 0x110998: run (coredumpctl.c:1087)
==16431== by 0x110A45: main (coredumpctl.c:1100)
==16431==
==16431== 64 bytes in 1 blocks are still reachable in loss record 6 of 13
==16431== at 0x4838748: malloc (vg_replace_malloc.c:298)
==16431== by 0x483AD63: realloc (vg_replace_malloc.c:826)
==16431== by 0x4902663: greedy_realloc (alloc-util.c:55)
==16431== by 0x49C7D7D: sd_bus_new (sd-bus.c:255)
==16431== by 0x49CC398: sd_bus_open_system_with_description (sd-bus.c:1271)
==16431== by 0x49CC4C6: sd_bus_open_system (sd-bus.c:1303)
==16431== by 0x49D4424: bus_default (sd-bus.c:3655)
==16431== by 0x49D44BC: sd_bus_default_system (sd-bus.c:3668)
==16431== by 0x110444: check_units_active (coredumpctl.c:1007)
==16431== by 0x110998: run (coredumpctl.c:1087)
==16431== by 0x110A45: main (coredumpctl.c:1100)
==16431==
==16431== 64 bytes in 1 blocks are still reachable in loss record 7 of 13
==16431== at 0x4838748: malloc (vg_replace_malloc.c:298)
==16431== by 0x483AD63: realloc (vg_replace_malloc.c:826)
==16431== by 0x4902663: greedy_realloc (alloc-util.c:55)
==16431== by 0x49CE54E: bus_rqueue_make_room (sd-bus.c:1786)
==16431== by 0x49C44FC: bus_socket_make_message (bus-socket.c:1087)
==16431== by 0x49C4C5B: bus_socket_read_message (bus-socket.c:1213)
==16431== by 0x49CE4CE: bus_read_message (sd-bus.c:1777)
==16431== by 0x49CE6AF: dispatch_rqueue (sd-bus.c:1814)
==16431== by 0x49D162E: process_running (sd-bus.c:2733)
==16431== by 0x49D20DD: bus_process_internal (sd-bus.c:2957)
==16431== by 0x49D21E8: sd_bus_process (sd-bus.c:2984)
==16431== by 0x49CF21E: bus_ensure_running (sd-bus.c:2053)
==16431==
==16431== 65 bytes in 1 blocks are still reachable in loss record 8 of 13
==16431== at 0x483AB1A: calloc (vg_replace_malloc.c:752)
==16431== by 0x496E5D6: getpeersec (socket-util.c:969)
==16431== by 0x49C291C: bus_get_peercred (bus-socket.c:594)
==16431== by 0x49C2CB2: bus_socket_start_auth (bus-socket.c:650)
==16431== by 0x49C3B09: bus_socket_connect (bus-socket.c:915)
==16431== by 0x49CBB08: bus_start_address (sd-bus.c:1103)
==16431== by 0x49CBFEA: sd_bus_start (sd-bus.c:1187)
==16431== by 0x49CC452: sd_bus_open_system_with_description (sd-bus.c:1294)
==16431== by 0x49CC4C6: sd_bus_open_system (sd-bus.c:1303)
==16431== by 0x49D4424: bus_default (sd-bus.c:3655)
==16431== by 0x49D44BC: sd_bus_default_system (sd-bus.c:3668)
==16431== by 0x110444: check_units_active (coredumpctl.c:1007)
==16431==
==16431== 181 bytes in 1 blocks are still reachable in loss record 9 of 13
==16431== at 0x483AD19: realloc (vg_replace_malloc.c:826)
==16431== by 0x49C4791: bus_socket_read_message (bus-socket.c:1143)
==16431== by 0x49CE4CE: bus_read_message (sd-bus.c:1777)
==16431== by 0x49CFA2C: sd_bus_call (sd-bus.c:2176)
==16431== by 0x1105F3: check_units_active (coredumpctl.c:1029)
==16431== by 0x110998: run (coredumpctl.c:1087)
==16431== by 0x110A45: main (coredumpctl.c:1100)
==16431==
==16431== 256 bytes in 1 blocks are still reachable in loss record 10 of 13
==16431== at 0x483880B: malloc (vg_replace_malloc.c:299)
==16431== by 0x496E740: getpeergroups (socket-util.c:998)
==16431== by 0x49C29BD: bus_get_peercred (bus-socket.c:599)
==16431== by 0x49C2CB2: bus_socket_start_auth (bus-socket.c:650)
==16431== by 0x49C3B09: bus_socket_connect (bus-socket.c:915)
==16431== by 0x49CBB08: bus_start_address (sd-bus.c:1103)
==16431== by 0x49CBFEA: sd_bus_start (sd-bus.c:1187)
==16431== by 0x49CC452: sd_bus_open_system_with_description (sd-bus.c:1294)
==16431== by 0x49CC4C6: sd_bus_open_system (sd-bus.c:1303)
==16431== by 0x49D4424: bus_default (sd-bus.c:3655)
==16431== by 0x49D44BC: sd_bus_default_system (sd-bus.c:3668)
==16431== by 0x110444: check_units_active (coredumpctl.c:1007)
==16431==
==16431== 256 bytes in 1 blocks are still reachable in loss record 11 of 13
==16431== at 0x4838748: malloc (vg_replace_malloc.c:298)
==16431== by 0x483AD63: realloc (vg_replace_malloc.c:826)
==16431== by 0x495D1A0: prioq_put (prioq.c:162)
==16431== by 0x49CF0EA: sd_bus_call_async (sd-bus.c:2023)
==16431== by 0x49CA0E6: bus_send_hello (sd-bus.c:581)
==16431== by 0x49CC019: sd_bus_start (sd-bus.c:1196)
==16431== by 0x49CC452: sd_bus_open_system_with_description (sd-bus.c:1294)
==16431== by 0x49CC4C6: sd_bus_open_system (sd-bus.c:1303)
==16431== by 0x49D4424: bus_default (sd-bus.c:3655)
==16431== by 0x49D44BC: sd_bus_default_system (sd-bus.c:3668)
==16431== by 0x110444: check_units_active (coredumpctl.c:1007)
==16431== by 0x110998: run (coredumpctl.c:1087)
==16431==
==16431== 856 bytes in 1 blocks are still reachable in loss record 12 of 13
==16431== at 0x483AB1A: calloc (vg_replace_malloc.c:752)
==16431== by 0x49A1F33: bus_message_from_header (bus-message.c:458)
==16431== by 0x49A22B1: bus_message_from_malloc (bus-message.c:535)
==16431== by 0x49C459B: bus_socket_make_message (bus-socket.c:1099)
==16431== by 0x49C4C5B: bus_socket_read_message (bus-socket.c:1213)
==16431== by 0x49CE4CE: bus_read_message (sd-bus.c:1777)
==16431== by 0x49CFA2C: sd_bus_call (sd-bus.c:2176)
==16431== by 0x1105F3: check_units_active (coredumpctl.c:1029)
==16431== by 0x110998: run (coredumpctl.c:1087)
==16431== by 0x110A45: main (coredumpctl.c:1100)
==16431==
==16431== 1,856 bytes in 1 blocks are still reachable in loss record 13 of 13
==16431== at 0x483880B: malloc (vg_replace_malloc.c:299)
==16431== by 0x49C6EDF: malloc_multiply (alloc-util.h:78)
==16431== by 0x49C7C81: sd_bus_new (sd-bus.c:235)
==16431== by 0x49CC398: sd_bus_open_system_with_description (sd-bus.c:1271)
==16431== by 0x49CC4C6: sd_bus_open_system (sd-bus.c:1303)
==16431== by 0x49D4424: bus_default (sd-bus.c:3655)
==16431== by 0x49D44BC: sd_bus_default_system (sd-bus.c:3668)
==16431== by 0x110444: check_units_active (coredumpctl.c:1007)
==16431== by 0x110998: run (coredumpctl.c:1087)
==16431== by 0x110A45: main (coredumpctl.c:1100)
==16431==
==16431== LEAK SUMMARY:
==16431== definitely lost: 0 bytes in 0 blocks
==16431== indirectly lost: 0 bytes in 0 blocks
==16431== possibly lost: 0 bytes in 0 blocks
==16431== still reachable: 3,680 bytes in 13 blocks
==16431== suppressed: 0 bytes in 0 blocks
==16431==
We want to propagate the return value from gdb, hence this commit makes
use of the liberalization of DEFINE_MAIN_FUNCTION_WITH_POSITIVE_FAILURE()
in previous commit.
Lennart Poettering