Ryan Hendrickson [Fri, 30 Apr 2021 16:47:10 +0000 (12:47 -0400)]
core: apply LogLevelMax to messages about units
This commit applies the filtering imposed by LogLevelMax on a unit's
processes to messages logged by PID1 about the unit as well.
The target use case for this feature is a service that runs on a timer
many times an hour, where the system administrator decides that writing
a generic success message to the journal every few minutes or seconds
adds no diagnostic value and isn't worth the clutter or disk I/O.
Debian has now been updated to patch the issue, so SemaphoreCI should
no longer fail. The fix has also been backported to the affected
stable branches.
Basically the same scenario as in a33e2692e162671f0d97856ad2f49a2620a1ec10, where `awk` exits as soon
as it finds a match, thus sending SIGPIPE to `ldd` if it's not fast
enough. That, in combination with `set -o pipefail` causes random &
unexpected fails, like:
```
No journal files were found.
-rw-r----- 1 root root 16777216 Apr 30 10:31
/var/tmp/TEST-01-BASIC_sanitizers-nspawn/system.journal
TEST-01-BASIC RUN: Basic systemd setup [OK]
systemd is not linked against the ASan DSO
gcc does this by default, for clang compile with -shared-libasan
make: *** [Makefile:2: clean-again] Error 1
make: Leaving directory '/build/test/TEST-01-BASIC'
```
Use BIOS characteristics to distinguish EC2 bare-metal from VMs
DMI vendor information fields do not provide enough information for us to
distinguish between Amazon EC2 virtual machines and bare-metal instances.
SMBIOS provides a BIOS Information
table (https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf
Ch. 7) that provides a field to indicate that the current machine is a virtual
machine. On EC2 virtual machine instances, this field is set, while bare-metal
instances leave this unset, so we inspect the field via the kernel's
/sys/firemware/dmi/entries interface.
Bertrand Jacquin [Sun, 11 Oct 2020 20:25:00 +0000 (21:25 +0100)]
virt: detect Amazon EC2 Nitro instance
Amazon EC2 Nitro hypervisor is technically based on KVM[1], which
systemd-detect-virt identify propely from CPUID. However the lack of
CPUID on aarch64 (A1, T4 instance type) prevents a correct
identification, impacting hostnamectl and systemd-random-seed. Instead
it's possible to identify virtualization from DMI vendor ID.
Prior to this commit:
# hostnamectl
Static hostname: n/a
Transient hostname: ip-10-97-8-12
Icon name: computer
Machine ID: 8e3772fbcfa3dd6f330a12ff5df5a63b
Boot ID: b7b7e2fe0079448db664839df59f9817
Operating System: Gentoo/Linux
Kernel: Linux 5.4.69-longterm
Architecture: arm64
After this commit:
# hostnamectl
Static hostname: n/a
Transient hostname: ip-10-97-8-12
Icon name: computer-vm
Chassis: vm
Machine ID: 8e3772fbcfa3dd6f330a12ff5df5a63b
Boot ID: bd04da57084e41078f20541101867113
Virtualization: amazon
Operating System: Gentoo/Linux
Kernel: Linux 5.4.69-longterm
Architecture: arm64
Yu Watanabe [Sun, 7 Mar 2021 06:35:33 +0000 (15:35 +0900)]
udev,sd_device: also save map from device ID to watch handle in /run/udev/watch
Previously, watch handle is saved in the udev databse. But in most cases,
the handle saved in the database is not updated. Especially, when udevd
is restarted, the inotify watch is restarted, but the database is not
updated.
Moreover, it is not necessary to save watch handle in the database, as
the handle is only take a effect during udevd is running, and the value
is meaningless when udevd is restarted.
So, this makes the opposite map from device ID to watch handle is saved
in /run/udev/watch as a symbolic link, and the handle not saved in the
database anymore.
Yu Watanabe [Sat, 6 Mar 2021 08:02:11 +0000 (17:02 +0900)]
udev: also propagate error in udev_rules_apply_to_event() on remove event
When udev rules are not applied correctly, then run program lists is
not perfect. So, udev_event_execute_run() later in
worker_process_device() should not be called.
Yu Watanabe [Sat, 6 Mar 2021 07:09:23 +0000 (16:09 +0900)]
udev: do not store inotify fd in a global variable
When manager_exit() or manager_free() is called, the global variable in
udev-watch.c is not set '-1'. Of course, that is safe, as the event source
for the inotify fd is unref()ed in manager_exit() and manager_free().
But let's not store fd globally.
Now, RoutesToDNS= and RoutesToNTP= are enabled by default on DHCPv4
client. So, if DHCP server picks up DNS or NTP servers from uplink,
then the routes may break CI environment.
systemd-coredump: Add conflict with shutdown.target
Otherwise a coredump started at the inconvinient moment can stop
shutdown.target leaving the system in a halfway-down state:
Pulling in shutdown.target/start from systemd-poweroff.service/start
Added job shutdown.target/start to transaction.
...
Keeping job shutdown.target/start because of systemd-poweroff.service/start
...
[ OK ] Stopped target Remote File Systems.
shutdown.target: starting held back, waiting for: systemd-networkd.socket
sysinit.target: stopping held back, waiting for: remount_tmp.service
systemd-coredump.socket: Incoming traffic
...
systemd-coredump@0-243-0.service: Trying to enqueue job systemd-coredump@0-243-0.service/start/replace
Added job systemd-coredump@0-243-0.service/start to transaction.
Pulling in systemd-journald.socket/start from systemd-coredump@0-243-0.service/start
Added job systemd-journald.socket/start to transaction.
Pulling in system.slice/start from systemd-journald.socket/start
Added job system.slice/start to transaction.
Pulling in -.slice/start from system.slice/start
Added job -.slice/start to transaction.
Pulling in system-systemd\x2dcoredump.slice/start from systemd-coredump@0-243-0.service/start
Added job system-systemd\x2dcoredump.slice/start to transaction.
Pulling in system.slice/start from system-systemd\x2dcoredump.slice/start
Pulling in shutdown.target/stop from system-systemd\x2dcoredump.slice/start
Added job shutdown.target/stop to transaction.
...
Keeping job systemd-poweroff.service/stop because of umount.target/stop
Keeping job shutdown.target/stop because of systemd-coredump@0-243-0.service/start
The maximum allowed value of the sysfs device index entry was limited to
16383 (2^14-1) to avoid the generation of unreasonable onboard interface
names.
For s390 the index can assume a value of up to 65535 (2^16-1) which is
now allowed depending on the new naming flag NAMING_16BIT_INDEX.
Larger index values are considered unreasonable and remain to be
ignored.
network: do not set nexthop ID, gateway, and multipath routes simultaneously
See kernel's rtm_to_fib_config() in net/ipv4/fib_frontend.c and
rtm_to_fib6_config() in net/ipv6/route.c.
Note that if both gateway and multipath routes are specified, then
kernel ignores gateway. So, strictly speaking, setting both gateway and
multipath routes is allowed by kernel. But such situation is mostly
user's misconfiguration. Let's refuse it.
Note that the conditions newly added in route_configure() are redundant,
as all static configurations are already verified in
route_section_verify(), and dynamic configurations do not set
nexthop_id or multipath routes. Just for safety.
network: do not remove reject type routes more than once
Usually, removing non-existing addresses, routes, and etc, are safe.
However, when multiple interfaces lost their carriers simultaneously,
then manager_drop_routes() and manager_drop_nexthop() are called multiple
times. If a route with a blackhole nexthop is removed in that process,
the later removal requests of the route fail with -EINVAL, rathar
than -ESRCH, as the corresponding nexthop does not exist anymore.
So, let's not remove routes which managed by Manager more than once.
basic/missing-syscalls: only emit one warning about missing numbers
The ifdef pattern is the same for all syscalls, so most of the time, if one is
not defined, all others will too. So let's reduce the noise a bit and emit one
warning in case the support for the architecture is fully missing. (Current
template was copied over from before when we added numbers for each syscall by
hand and stopped making sense when we started generating the header from a
table that is expected to have all syscall numbers.)
hwdb: 60-keyboard:: Update Dell Privacy Local Mic Mute Hotkey (#19261)
This patch fix scancode 0x120001 mapping to key code F20 micmute
The previous scancode is not correct, it will cause the micmute
hotkey no function when testing the mic mute
https://github.com/systemd/systemd/pull/19316 failed with:
[1065/1670] Linking target systemd-hwdb
--- command ---
14:28:29 /root/src/test/hwdb-test.sh
--- stdout ---
./systemd-hwdb does not exist, please build first
I'm not sure what is going on here… In principle meson says that tests may be
called from any directory, but in practice is was always the build directory.
So far we were relying on systemd-hwdb being present in '.', and this worked.
Either way, it's nicer to pass the exact path, so let's do that.
Add support for conditions on the machines firmware
This allows to limit units to machines that run on a certain firmware
type. For device tree defined machines checking against the machine's
compatible is also possible.
network: neighbor: Always add neighbors with replace
We were duplicating setting flags for the message and a combination of
NLM_F_APPEND and NLM_F_CREATE which does not make sense. We should have
been using NLM_F_REPLACE and NLM_F_CREATE since the kernel can
dynamically create neighbors prior to us adding an entry. Otherwise, we
can end up with cases where the message will time out after ~25s even
though the neighbor still gets added. This delays the rest of the setup
of the interface even though the error is ultimately ignored.
system-conf: drop reference to ShutdownWatchdogUsec=
Commit 65224c1d0e50667a87c2c4f840c49d4918718f80 renamed ShutdownWatchdogUsec
into RebootWatchdogUsec but left a reference of ShutdownWatchdogUsec in
system.conf.
projects / thirdparty / systemd.git / log
