* 'signal_safety' of https://github.com/crrodriguez/util-linux:
sulogin: only assign to variables written by signal handlers
hardlink: calling putchar is off-limits on a signal handler
hardlink: last_signal should be a volatile sig_atomic_t
pg: calling exit on signal handler is not allowed
lib📟 fix signal safety issues
write: signal_received should be volatile qualified
flock: timeout_expired must be volatile qualified
last: should not use errx/warnx on signal handlers
su-common: bool is a distinct type in c2x
fsck: only assign to cancel_requested
fsck: use sig_atomic_t type fot signal handler global vars
* use safe xstrncpy() rather than strcpy()
* use sizeof() for static buffers rather than macro with real size
(this solution is more robust for future code changes)
* use xcalloc() to zeroize allocated memory
Signed-off-by: Karel Zak <kzak@redhat.com>
Using putchar or any stdio function in signal handlers will
lead to funny results as they cannot be async signal safe.
One can write to stdout instead.
This command implements waiting for the exit of multiple processes.
Especially it allows to wait for process that are not children of the
current process.
In contrast to wait(1P) it does not allow to retrieve the processes exit
codes.
* 'meson-debian' of https://github.com/zeha/util-linux:
meson: install uuidd.rc with -Dsysvinit=enabled
meson: fix pkg-config name of libaudit
meson: fix build with -Dselinux=enabled
Document the behaviour of an empty `expression` argument, and of `/` in
the `expression` and `replacement` arguments.
I also tried to make it slightly clearer that `-s` changes where a
symlink points, but doesn't change the thing that it points at.
Close#1930.
The original code assumed 48bit addresses. This assumption came
from linux running on x86_64. As reported in #1930, Linux on
sparc64 uses 64bit addresses.
Tested-by: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
In my plan, lsfd will need the information of the backing device for
"nsfs" file system before collecing the information about th namespaces
associated with fds.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
The current code updates the header only when the priority has been
changed. It's incorrect because wanted is a valid header or each entry
(don't forget that logger for stdin use-case is used in pipe to log
long-time running processes).
This patch also fixes the initial timestamp; it was originally generated
on logger startup, it now generates the header on the first message.
$ (sleep 2; date; sleep 2; date; sleep 2; date) | logger --stderr --no-act
old:
<13>Nov 1 10:42:14 kzak: Tue Nov 1 10:42:16 AM CET 2022
<13>Nov 1 10:42:14 kzak: Tue Nov 1 10:42:18 AM CET 2022
<13>Nov 1 10:42:14 kzak: Tue Nov 1 10:42:20 AM CET 2022
new:
<13>Nov 1 10:19:02 kzak: Tue Nov 1 10:19:02 AM CET 2022
<13>Nov 1 10:19:04 kzak: Tue Nov 1 10:19:04 AM CET 2022
<13>Nov 1 10:19:06 kzak: Tue Nov 1 10:19:06 AM CET 2022
Fixes: https://github.com/util-linux/util-linux/issues/1866
Signed-off-by: Karel Zak <kzak@redhat.com>
* 'lsfd-s390-proc-net-L3' of https://github.com/masatake/util-linux:
lsfd: unify the code for reading /proc/net/tcp and udp
lsfd: make the logic for verifying the initial line of /proc/net/{tcp,udp} more flexible
In production we've had several incidents over the years where a process
has a signal handler registered for SIGHUP or one of the SIGUSR signals
which can be used to signal a request to reload configs, rotate log
files, and the like. While this may seem harmless enough, what we've
seen happen repeatedly is something like the following:
1. A process is using SIGHUP/SIGUSR[12] to request some
application-handled state change -- reloading configs, rotating a log
file, etc;
2. This kind of request is deprecated and removed, so the signal handler
is removed. However, a site where the signal might be sent from is
missed (often logrotate or a service manager);
3. Because the default disposition of these signals is terminal, sooner
or later these applications are going to be sent SIGHUP or similar
and end up unexpectedly killed.
I know for a fact that we're not the only organistion experiencing this:
in general, signal use is pretty tricky to reason about and safely
remove because of the fairly aggressive SIG_DFL behaviour for some
common signals, especially for SIGHUP which has a particularly ambiguous
meaning. Especially in a large, highly interconnected codebase,
reasoning about signal interactions between system configuration and
applications can be highly complex, and it's inevitable that on occasion
a callsite will be missed.
In some cases the right call to avoid this will be to migrate services
towards other forms of IPC for this purpose, but inevitably there will
be some services which must continue using signals, so we need a safe
way to support them.
This patch adds support for the -r/--require-handler flag, which checks
if a userspace handler is present for the signal being sent. If it is
not, the process will be skipped.
With this flag we can enforce that all SIGHUP reload cases and SIGUSR
equivalents use --require-handler. This effectively mitigates the case
we've seen time and time again where SIGHUP is used to rotate log files
or reload configs, but the sending site is mistakenly left present after
the removal of signal handler, resulting in unintended termination of
the process.
Signed-off-by: Chris Down <chris@chrisdown.name>
The format of /proc/net/udp was changed in
6c25449e1a32 ("net: udp: fix alignment problem in udp4_seq_show()").
This kind of change can be applied to /proc/net/tcp, too.
Co-Authored-by: Thomas Weißschuh <thomas@t-8ch.de>
Co-Authored-by: Masatake YAMATO <yamato@redhat.com>
Let's mark the columns by no-extreme libsmartcols flag. It makes
output more compact if there are too long mount paths.
Signed-off-by: Karel Zak <kzak@redhat.com>
isc-utils/lsfd-sock-xinfo.c:588:34: error: extra ';' outside of a function [-Werror,-Wextra-semi]
define_fill_column_func(tcp, TCP);
^
misc-utils/lsfd-sock-xinfo.c:703:34: error: extra ';' outside of a function [-Werror,-Wextra-semi]
define_fill_column_func(udp, UDP);
^
Addresses: 92a0dbce7c
Signed-off-by: Karel Zak <kzak@redhat.com>
