Although extremely unlikely, there is a race present in solely checking the
$LISTEN_PID environment variable, due to PID recycling. Fix that by introducing
$LISTEN_PIDFDID, which contains the 64-bit ID of a pidfd for the child process
that is not subject to recycling.
- Make sure forward headers have the iwyu pragma to always keep them
- Make sure we always include the daemon specific forward header
instead of shared-forward.h
- Remove shared-forward.h include where the daemon specific forward
header is already included
Needed to implement support for RootHashSignature=/RootVerity=/RootHash=
and friends when going through mountfsd, for example with user units,
so that system and user units provide the same features at the same
level
When varlink parameters are empty, omit the "parameters" field entirely
rather than sending "parameters":{}. This reduces message size and
follows varlink specification which allows parameters to be omitted.
The implementation supports three equivalent representations for empty
parameters: field omission, JSON null, and empty object {}. All three
are accepted on input for backward compatibility.
Fixes: #38474
Let's not leak details from src/shared and src/libsystemd into
src/basic, even though you can't actually do anything useful with
just forward declarations from src/shared.
The sd-forward.h header is put in src/libsystemd/sd-common as we
don't have a directory for shared internal headers for libsystemd
yet.
Let's also rename forward.h to basic-forward.h to keep things
self-explanatory.
This removes iptables/libiptc backend support in firewall-util, as
already announced by 5c68c51045.
Then, this drops meaningless `FirewallContext` wrapper.
This is ultimately preparation for making systemd-creds's --with-key=
switch also accessible via Varlink, because it uses "+" inside an the
enum name. It makes sense to to allow this generally however.
When we are running in chroot, safe_fork() with FORK_MOUNTNS_SLAVE fails
with the following eror:
```
Failed to set mount propagation to MS_SLAVE for all mounts: Invalid argument
```
Let's skip the test cases when we are running in chroot.
I'm seeing this in the initrd (with the dev_ksmg_record line added to clarify
where the error is coming from):
[ 6.114232] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.2
[ 6.116842] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.2".
[ 6.134115] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.2".
[ 6.139427] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.144327] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.149442] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.155091] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.160118] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.164814] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.169201] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.173990] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.183104] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.187746] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.192825] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.197733] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.203015] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.207184] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.211943] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.216703] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.221944] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.226803] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.231238] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.236078] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.241845] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.247976] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.252545] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.256146] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.260651] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.265151] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.269755] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.276206] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.280034] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.284603] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.288710] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.293312] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.297763] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.302438] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.306948] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.310797] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.315097] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.319033] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.323593] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.328834] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.333057] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.337644] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.341152] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.345436] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.349824] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.354306] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.358131] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.366568] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.371139] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.375207] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.378681] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.382820] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.387143] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.392192] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.397109] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.400991] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.405992] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.410889] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.414730] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.418266] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.422575] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.429942] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.433780] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.438509] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.442293] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.447236] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.453336] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.458031] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.461948] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.465883] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.470072] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.476196] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.481182] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.484938] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.491322] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.497289] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.501935] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.505217] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.509819] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.516078] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.520942] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.525178] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.528505] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.534669] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.539353] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.543035] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.547441] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.553211] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.557452] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.562468] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.566955] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.1
[ 6.570846] systemd-journald[251]: Too many messages being logged to kmsg, ignoring
The error message was misleading, since it sounds like there's an issue with
symlinks, but the device simply doesn't exist. But I think we should suppress
the message altogether. journald spewing messages like this fills up the logs
for no benefit. The sd_device_new* functions can legitimately be used for
"invalid" devices, e.g. to check if they even exist. We have no idea for what
purpose the caller is creating the device object, so let's not log this at all.
The caller can log if appropriate.
Function execute_directories logged in a way that was meaningless
without additional context:
systemd[1]: No executables found.
In execute_strv this was partially rectified by extracting the directory
name from one of the directories and using this as the identifier. But
the directory name is not always meaningful, and can also be set from
an environment variable. Let's simplify things by providing a fixed name
that can be used consistently in all log messages. In particular this will
make error messages easier to understand if users report just the error
without additional context.
This reverts commit 490aa05ca1.
As commented https://github.com/systemd/systemd/pull/38569#discussion_r2284978273,
the commit makes autofs check bypassed. Before the commit, when
CHASE_NO_AUTOFS is set, we did not shortcut chasing paths, and refused
any autofs mount points in the path. However, with the commit, the flag
was swapped but even when CHASE_AUTOFS is unset, the autofs check may be
skipped.
To fix the issue, rather than swapping the flag, we should introduce
another flag, say CHASE_TRIGGER_AUTOFS. This revert the commit, and in a
later commit, the new flag will be introduced.
Since https://github.com/systemd/systemd/commit/c5de7b14ae2e08d267d8d75bc88934ac6aa7dcd6
file searching implies a new mount api syscall by default,
to trigger automounts.
This is problematic in NSS plugins, as they are dlopen'ed inside
processes by glibc, for two reasons.
First of all, potentially searching on a networked filesystem
automount could lead to nasty surprises, such as the process
responsible for setting up the network filesystem trying to
search on that same filesystem.
More importantly, the new mount api syscall was never part of
the filesystem seccomp filter that we provide by default, and
given mounting/remounting/bind mounting is one of the possible
ways to bypass sandboxing it is very likely not allowed when
custom filters are used in sandboxed processes, if they don't
need to do these operations otherwise.
The filesystem seccomp mask we provide has been updated, however
this only takes effect on the next restart of a service. When
systemd is upgraded via a package upgrade, the new nss plugin is
installed and will be immediately dlopen'ed by glibc when needed,
without waiting for the process to restart, which means the existing
seccomp filter applies, causing the filter to trigger.
Given it's not really possible for any arbitrary program to
predict which NSS modules glibc will load, given programs do not
configure that and instead nsswitch is set up by the sysadmin,
it's impossible to handle at each process level. It's also not
possible to know when it will be triggered, given the plugin
is not linked in each binary tools like need-restart cannot
even pre-emptively restart services that may be affected.
This means in practice, upgrading from systemd << v258 to >= v258
requires a reboot to avoid either subtle or catastrophic system
failures.
By avoiding to trigger automounts in nss-systemd we can avoid
both issues.
userdb drop-ins are searched for in:
/etc/userdb/
/run/userdb/
/run/host/userdb/
/usr/local/lib/userdb/
/usr/lib/userdb/
none of which are supported as automounts anyway.
Note that this happens only when the userdbd service is not running,
as otherwise nss-systemd will go through the varlink IPC, rather than
doing the searches in-process.
So invert CHASE_NO_AUTOFS to CHASE_AUTOFS and set it in the places where
we do want to trigger automounts, like looking for the ESP.
Follow-up for https://github.com/systemd/systemd/commit/c5de7b14ae2e08d267d8d75bc88934ac6aa7dcd6
Fixes https://github.com/systemd/systemd/issues/38565
Previously we didn't provide any install_callback to
sd_bus_add_match_async() so in case AddMatch() method call timed out we
destroyed the bus connection. This seems overly aggressive and simply
updating the sd_bus_track object accordingly should be enough.
Follow-up for 37ce3fd2b7.
Fixes#32381
It is not easy to understand what happens to a journal file
even with debug logs enabled. Add more dbg messages around operations
started by users to make it possible to follow the flow of operations.
As discussed in https://github.com/systemd/systemd/issues/38399, "ordinary"
systems can have the field table with a large number of values, causing journal
rotation to occur early. For example, audit generates a log of fields:
$ journalctl --fields | rg -c '^_?AUDIT'
114
It seems that the "structured log" capabilities of the journal are being use
more than in the past. Looking at some journal files on my system, it seems
the field hash table field is quite high in many cases:
$ build/test-journal-dump /var/log/journal/*/* | rg 'table fill'
Data hash table fill: 15.1%
Field hash table fill: 69.1%
Data hash table fill: 4.9%
Field hash table fill: 32.4%
Data hash table fill: 10.2%
Field hash table fill: 34.2%
Data hash table fill: 9.9%
Field hash table fill: 37.2%
Data hash table fill: 26.8%
Field hash table fill: 21.9%
Data hash table fill: 35.6%
Field hash table fill: 22.8%
Data hash table fill: 25.5%
Field hash table fill: 54.1%
Data hash table fill: 3.4%
Field hash table fill: 43.8%
Data hash table fill: 75.0%
Field hash table fill: 70.3%
Data hash table fill: 75.0%
Field hash table fill: 63.1%
Data hash table fill: 75.0%
Field hash table fill: 74.2%
Data hash table fill: 35.6%
Field hash table fill: 43.2%
Data hash table fill: 35.5%
Field hash table fill: 75.4%
Data hash table fill: 75.0%
Field hash table fill: 59.8%
Data hash table fill: 75.0%
Field hash table fill: 56.5%
Data hash table fill: 16.9%
Field hash table fill: 76.3%
Data hash table fill: 18.1%
Field hash table fill: 76.9%
Data hash table fill: 75.0%
Field hash table fill: 42.0%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 32.1%
Data hash table fill: 75.0%
Field hash table fill: 21.9%
Data hash table fill: 75.0%
Field hash table fill: 21.9%
Data hash table fill: 75.0%
Field hash table fill: 21.9%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 21.9%
Data hash table fill: 75.0%
Field hash table fill: 22.5%
Data hash table fill: 9.6%
Field hash table fill: 53.8%
Data hash table fill: 75.0%
Field hash table fill: 22.2%
Data hash table fill: 75.0%
Field hash table fill: 22.2%
Data hash table fill: 75.0%
Field hash table fill: 22.2%
Data hash table fill: 35.6%
Field hash table fill: 75.1%
Data hash table fill: 33.6%
Field hash table fill: 50.2%
Data hash table fill: 75.0%
Field hash table fill: 26.7%
Data hash table fill: 75.0%
Field hash table fill: 25.8%
Data hash table fill: 75.0%
Field hash table fill: 29.1%
Data hash table fill: 75.0%
Field hash table fill: 25.8%
Data hash table fill: 75.0%
Field hash table fill: 31.8%
Data hash table fill: 75.0%
Field hash table fill: 18.9%
Data hash table fill: 75.0%
Field hash table fill: 22.2%
Data hash table fill: 75.0%
Field hash table fill: 20.1%
Data hash table fill: 75.0%
Field hash table fill: 29.1%
Data hash table fill: 75.0%
Field hash table fill: 30.9%
Data hash table fill: 75.0%
Field hash table fill: 28.5%
Data hash table fill: 75.0%
Field hash table fill: 28.5%
Data hash table fill: 75.0%
Field hash table fill: 25.8%
Data hash table fill: 75.0%
Field hash table fill: 25.2%
Data hash table fill: 75.0%
Field hash table fill: 39.3%
Data hash table fill: 50.2%
Field hash table fill: 75.1%
Data hash table fill: 75.0%
Field hash table fill: 61.9%
Data hash table fill: 75.0%
Field hash table fill: 56.5%
Data hash table fill: 75.0%
Field hash table fill: 58.6%
Data hash table fill: 48.9%
Field hash table fill: 79.6%
Data hash table fill: 75.0%
Field hash table fill: 71.5%
Data hash table fill: 75.0%
Field hash table fill: 60.1%
Data hash table fill: 31.4%
Field hash table fill: 75.7%
Data hash table fill: 27.0%
Field hash table fill: 69.4%
Data hash table fill: 28.9%
Field hash table fill: 76.6%
Data hash table fill: 60.2%
Field hash table fill: 79.9%
Data hash table fill: 8.8%
Field hash table fill: 78.7%
Data hash table fill: 5.8%
Field hash table fill: 61.3%
Data hash table fill: 75.0%
Field hash table fill: 64.0%
Data hash table fill: 61.4%
Field hash table fill: 63.4%
Data hash table fill: 29.7%
Field hash table fill: 61.9%
Data hash table fill: 18.9%
Field hash table fill: 30.9%
Data hash table fill: 1.4%
Field hash table fill: 22.2%
Data hash table fill: 0.4%
Field hash table fill: 13.5%
Data hash table fill: 2.6%
Field hash table fill: 37.5%
Data hash table fill: 1.3%
Field hash table fill: 23.4%
Data hash table fill: 0.6%
Field hash table fill: 15.3%
Data hash table fill: 18.7%
Field hash table fill: 33.9%
Data hash table fill: 7.4%
Field hash table fill: 37.5%
Data hash table fill: 20.2%
Field hash table fill: 44.1%
Data hash table fill: 1.3%
Field hash table fill: 33.0%
Data hash table fill: 75.0%
Field hash table fill: 19.2%
Data hash table fill: 42.2%
Field hash table fill: 23.4%
Data hash table fill: 1.6%
Field hash table fill: 87.1%
Data hash table fill: 0.1%
Field hash table fill: 98.8%
Data hash table fill: 0.2%
Field hash table fill: 128.8%
Data hash table fill: 15.4%
Field hash table fill: 31.2%
Data hash table fill: 7.4%
Field hash table fill: 22.5%
Data hash table fill: 10.5%
Field hash table fill: 38.7%
Data hash table fill: 2.8%
Field hash table fill: 18.0%
Data hash table fill: 1.5%
Field hash table fill: 15.9%
Data hash table fill: 0.0%
Field hash table fill: 7.5%
Data hash table fill: 0.1%
Field hash table fill: 12.0%
Data hash table fill: 0.2%
Field hash table fill: 10.8%
Data hash table fill: 0.2%
Field hash table fill: 15.6%
Data hash table fill: 0.1%
Field hash table fill: 11.7%
Data hash table fill: 0.1%
Field hash table fill: 12.0%
Data hash table fill: 0.0%
Field hash table fill: 6.6%
Data hash table fill: 1.4%
Field hash table fill: 18.0%
Data hash table fill: 0.7%
Field hash table fill: 16.8%
Data hash table fill: 1.1%
Field hash table fill: 18.0%
Data hash table fill: 0.2%
Field hash table fill: 10.8%
Data hash table fill: 0.1%
Field hash table fill: 10.8%
Data hash table fill: 0.4%
Field hash table fill: 11.1%
Since filling of the field hash table to 75% normally causes file rotation,
let's double the default to make rotation happen less often.
We'll use 11kB more for the hash table, which should be fine, considering
that journal files are usually at least 8 MB.
Closes https://github.com/systemd/systemd/issues/38399.
It's easier to think about the size in "objects", not bytes. Let's convert to
bytes at the last moment.
Also drop some of the pointless size suffixes. In general, it's the size of the
variable that matters, not the constant that is written to it.
No functional change.
Luca Boccassi
Yu Watanabe
Lennart Poettering
Daniel Foster
Daan De Meyer
Luca Boccassi
Govind Venugopal
Ivan Kruglov
Mike Yuan
anthisfan
Zbigniew Jędrzejewski-Szmek
Michal Sekletar