It turns out that the kernel allows comm names higher than our expected limit
of 16.
$ wc -c /proc/*/comm|sort -g|tail -n3
35 /proc/1292317/comm
35 /proc/1293610/comm
36 /proc/1287112/comm
$ cat /proc/1287112/comm
kworker/u9:3-kcryptd/253:0
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.
Fix the following compile error:
src/basic/socket-util.h:187:30: error: implicit declaration of function 'strnlen'; did you mean 'strlen'? [-Werror=implicit-function-declaration]
Switching to K_UNICODE from other than L_XLATE can make the keyboard
unusable and possibly leak keypresses from X.
BugLink: https://launchpad.net/bugs/1803993
An ugly, ugly work-around for #11810. And no, we shouldn't have to do
this. This is something for AMD, the firmware or the kernel to
fix/work-around, not us. But nonetheless, this should do it for now.
Fixes: #11810
We don#t actually use all combinations, but it's kinda nice if we can
output all combinations in a test, and this is preparation so that we
can do so nicely.
three of these colors we never use, so let's drop them. Let's however
add a highlight version of grey, so that at least for all colors we do
define we have all possible styles defined.
Apparently all relevant terminals implement these sequences, including
the Linux kernel, rxvt, xterm, and of course gnome terminal. Hence it
should be OK to use them, and fixate the grey color in a way that maps
to the same color in all terminals.
Ideally we'd stick to the more symbolic colors that allow terminal
emulators to implement color styles, but this apparently doesn#t work,
since rxvt maps grey to something unreadable by default.
Note that this change has negative effects besides the non-themability
of the palette: the midrange grey this uses maps to regular white on the
linux console. However, that's probably not too bad: allowing things to
be unreadable on some terminals is probably worse than showing no color
on some terminals.
Fixes: #12482
Otherwise, the fuzzers will fail to compile with MSan:
```
../../src/systemd/src/basic/random-util.c:64:40: error: use of undeclared identifier 'sucess'; did you mean 'success'?
msan_unpoison(&success, sizeof(sucess));
^~~~~~
success
../../src/systemd/src/basic/alloc-util.h:169:50: note: expanded from macro 'msan_unpoison'
^
../../src/systemd/src/basic/random-util.c:38:17: note: 'success' declared here
uint8_t success;
^
1 error generated.
[80/545] Compiling C object 'src/basic/a6ba3eb@@basic@sta/process-util.c.o'.
ninja: build stopped: subcommand failed.
Fuzzers build failed
```
In program output, highlighting warnings with ANSI_HIGHLIGHT is not enough,
because it doesn't stand out enough. Yellow is more appropriate.
I was worried that yellow wouldn't be visible on white background, but (at
least gnome-terminal) uses a fairly dark yellow that is fully legible on white
and light-colored backgrounds. We also used yellow in many places,
e.g. systemctl, so this should be fine.
Note: yellow is unreadable on urxvt with white background (urxvt +rv). But
grey, which we already used, is also unreadable, so urxvt users would have
to disable colors anyway, so this change does not make the problem
intrinsically worse. See
https://github.com/systemd/systemd/issues/12482#issuecomment-490374210.
Let's be a bit paranoid and hash the 16 bytes we get from getauxval()
before using them. AFter all they might be used by other stuff too (in
particular ASLR), and we probably shouldn't end up leaking that seed
though our crappy pseudo-random numbers.
The old flag name was a bit of a misnomer, as /dev/urandom cannot be
"drained". Once it's initialized it's initialized and then is good
forever. (Only /dev/random has a concept of 'draining', but we never use
that, as it's an obsolete interface).
The flag is still useful though, since it allows us to suppress accesses
to the random pool while it is not initialized, as that trips up the
kernel and it logs about any such attempts, which we really don't want.
Unfortunately the warning must be known, or otherwise the pragma generates a
warning or an error. So let's do a meson check for it.
Is it worth doing this to silence the warning? I think so, because apparently
the warning was already emitted by gcc-8.1, and with the recent push in gcc to
catch more such cases, we'll most likely only get more of those.
This is another attempt at d4b604baea and #12438
Instead of blindly using the extra allocated space, let's do so only
after telling libc about it, via a second realloc(). The second
realloc() should be quick, since it never has to copy memory around.
This reverts commit d4b604baea.
When realloc() is called, the extra memory between the originally
requested size and the end of malloc_usable_size() isn't copied. (at
least with the version of glibc that currently ships on Arch Linux)
As a result, some elements get lost and use uninitialized memory, most
commonly 0, and can lead to crashes.
fixes#12384
If a container manager does not set $container, we could end up
in a strange situation when detect-virt returns container-other when
run as non-pid-1 and none when run as pid-1.
So apparently there are two reasons why accept() can return EOPNOTSUPP:
because the socket is not a listening stream socket (or similar), or
because the incoming TCP connection for some reason wasn't acceptable to
the host. THe latter should be a transient error, as suggested on
accept(2). The former however should be considered fatal for
flush_accept(). Let's fix this by explicitly checking whether the socket
is a listening socket beforehand.
kernel-4.15's if_ether.h has a bug that the header does not provide
'struct ethhdr'. The bug is introduced by
6926e041a8920c8ec27e4e155efa760aa01551fd (4.15-rc8)
and fixed by da360299b6734135a5f66d7db458dcc7801c826a (4.16-rc3).
This makes systemd built with kernel-4.15 headers.
Fixes#12319.
The L2TP_ATTR_UDP_ZERO_CSUM6_{TX,RX} attributes are introduced by
6b649feafe10b293f4bd5a74aca95faf625ae525, which is included in
kernel-3.16. To support older kernel, let's import the header.
Fixes#12300.
Zbigniew Jędrzejewski-Szmek
Topi Miettinen
Yu Watanabe
Andrej Valek
Chen Qi
Lennart Poettering
Balint Reczey
Evgeny Vereshchagin
Mike Gilbert
Aaron Barany
Ben Boeckel
Benjamin Robin