If the removal of the devlink is requested due to this is a 'remove' event,
it is trivial that the devlink will not be owned by this device anymore.
Let's read the devlink and if it points to our device node, then we need
to update the devlink. If it points to another device node, then it is already
owned by another device, hence we should not touch it and keep it as is.
Fixes#37823.
Fix regression introduced in a7bfb9f76b,
where busy loop can be started with a request for following logs with a
range header set with num_skip value pointing beyond the end of the
journal. In that case the reader callback returns 0 and is called
immediately again, usually causing an endless loop that is not recovered
even when new journal events are added.
The bug does not occur if num_skip is not set - in that case if no
journal entries matching the filters are added, the tight loop is
avoided by the sd_journal_wait().
To fix the issue, when no matching journal events are available, set a
flag and reuse the backoff mechanism using the sd_journal_wait().
Link: https://github.com/home-assistant/operating-system/issues/4190
As prompted by #38393, search domains may be large when a complicated
network setting is used, especially when VPN is used. Let's bump the
limit to 1024.
Note, this does not bump the maximum number of DNS servers, as setting
thousands of DNS servers is spurious and mostly meaningless. Let's keep
the maximum for a while until someone requests to also bump them.
Continuation of b950ee06e6.
Closes#38393.
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.
drained() checks PTYForward.master_readable flag, but it may be
tentatively unset due to a tentative error like EAGAIN in the previous
IO event. Let's try to call shovel() one more time, which re-read the
master and call drained() at the end. Otherwise, we may lost some data.
When PTYForward.done is set, the PTYForward.master is already
disconnected. Let's not try to read the already closed file descriptor.
Also, if we previously received vhangup, then it is not necessary to
re-read the device to check vhangup, as we already know.
This also make the check slightly delayed, and use a defer event source,
to make the function can be called safely in another event source.
Currently, pty_forward_set_ignore_vhangup() is only used for disabling
the flag. To make the function also disable PTY_FORWARD_IGNORE_INITIAL_VHANGUP
flag, this renames it to pty_forward_honor_vhangup().
Also, for consistency, pty_forward_get_ignore_vhangup() and
ignore_vhangup() are replaced with pty_forward_vhangup_honored().
Previously, do_shovel() sometimes call pty_forward_done(), and
its caller shovel() also call pty_forward_done(). Let's move all
pty_forward_done() calls to shovel(), and do_shovel() not call it.
No functional change, just refactoring.
We had errno_to_name() which works for "known" errnos, and returns NULL for
unknown ones, and then ERRNO_NAME which always returns an answer, possibly just
a number as a string, but requires a helper buffer.
It is possible for the kernel to add a new errno. We recently learned that some
architectures define custom errno names. Or for some function to unexpectedly
return a bogus errno value. In almost all cases it's better to print that value
rather than "n/a" or "(null)". So let's use ERRNO_NAME is most error handling
code. Noteably, our code wasn't very good in handling the potential NULL, so
in various places we could print "(null)". Since this is supposed to be used
most of the time, let's shorten the names to ERRNO_NAME/errno_name.
There are a few places where we don't want to use the fallback path, in
particular for D-Bus error names or when saving the error name. Let's rename
errno_to_name() to errno_name_no_fallback() to make the distinction clearer.
Follow-up for cfb7abc7fc
For whatever reason, ly is setting $XDG_RUNTIME_DIR before invoking
PAM session on its own
(https://github.com/fairyglade/ly/blob/v1.1.1/src/auth.zig#L45),
which after the offending commit will potentially be unset again
by pam_systemd. Let's restore the previous behavior if not switching area.
Fixes#38402
The usual pattern of using colors to distinguish the mount path (/efi/)
and the rest is used. If the file cannot be read for reasons other than
-ENOENT, the error message is highlighted.
I considered a few places where to add this, but this section seems the
most reaosonable. We already print the 'token' there, which is also part of
the configuration.
Boot Loader Entry Locations:
ESP: /efi (/dev/disk/by-partuuid/31659406-5a17-46ec-8195-0dea1667db58)
config: /efi//loader/loader.conf
XBOOTLDR: /boot (/dev/disk/by-partuuid/4f8a8fe9-4b45-4070-9e9b-a681be51c902, $BOOT)
token: fedora
With the previous commit, now CHASE_MUST_BE_DIRECTORY can be set with
CHASE_NONEXISTENT. Let's unconditionally set the flag to chase the
directory part of the conf file.
Otherwise, if it is called with CHASE_NONEXISTENT, when we call
stat_verify_directory()/_regular() the struct stat is for one of the
parent directory, rather than for the result path.
With this change, we can safely specify CHASE_MUST_BE_DIRECTORY/REGULAR
with CHASE_NONEXISTENT.
More importantly, chaseat() internally sets CHASE_MUST_BE_DIRECTORY when
the input path ends with "/", "/,", "/..". Hence, without this change,
we cannot specify CHASE_NONEXISTENT safely.
Follow-up for 90b9f7a07e.
Fixes the following error when running with sanitizers:
```
TEST-87-AUX-UTILS-VM.sh[670]: + bootctl install --make-entry-directory=yes
TEST-87-AUX-UTILS-VM.sh[695]: Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed" to "/boot/EFI/systemd/systemd-bootx64.efi".
TEST-87-AUX-UTILS-VM.sh[695]: Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed" to "/boot/EFI/BOOT/BOOTX64.EFI".
TEST-87-AUX-UTILS-VM.sh[695]: Created "/boot/fedora".
TEST-87-AUX-UTILS-VM.sh[695]: Random seed file /boot/loader/random-seed successfully refreshed (32 bytes).
TEST-87-AUX-UTILS-VM.sh[695]: ../src/shared/efi-api.c:618:38: runtime error: left shift of 243 by 24 places cannot be represented in type 'int'
```
We want to check if the magic we got from statfs() is one of the magics listed
for one of the file systems in the given group. To do this, we'd iteratate over
the file system names, convert each name to an array of magics, and compare
those to the one we got. We were using gperf-generated lookup table for this,
so the string lookups were quick, but still this seems unnecessarily complex.
Let's just generate a simple lookup function, because we can:
$ src/basic/filesystem-sets.py fs-in-group
bool fs_in_group(const struct statfs *st, FilesystemGroups fs_group) {
switch (fs_group) {
case FILESYSTEM_SET_BASIC_API:
return F_TYPE_EQUAL(st->f_type, CGROUP2_SUPER_MAGIC)
|| F_TYPE_EQUAL(st->f_type, CGROUP_SUPER_MAGIC)
|| F_TYPE_EQUAL(st->f_type, DEVPTS_SUPER_MAGIC)
|| F_TYPE_EQUAL(st->f_type, MQUEUE_MAGIC)
|| F_TYPE_EQUAL(st->f_type, PROC_SUPER_MAGIC)
|| F_TYPE_EQUAL(st->f_type, SYSFS_MAGIC)
|| F_TYPE_EQUAL(st->f_type, TMPFS_MAGIC);
case FILESYSTEM_SET_ANONYMOUS:
return F_TYPE_EQUAL(st->f_type, ANON_INODE_FS_MAGIC)
|| F_TYPE_EQUAL(st->f_type, PIPEFS_MAGIC)
|| F_TYPE_EQUAL(st->f_type, SOCKFS_MAGIC);
...
We flatten the nested lookup of group=>fs=>magic into a single level.
The compiler can work its magic here to make the lookup quick.
Previously, the gperf table was the main "source of truth", and additional
information (e.g. which file system names are obsolete) was scattered in
various files. We would then parse the gperf file, using python, awk, grep, and
bash, and use the results in various ways. This is hard to understand and
maintain. Let's replace all of this with a single python script that generates
the requested outputs as appropriate.
$ diff -u <(git show @{u}:src/basic/filesystems-gperf.gperf) \
<(src/basic/filesystem-sets.py gperf)
shows that the outputs are the same except for comments.
Similarly, 'src/basic/filesystem-sets.py fs-type-to-string' and
'src/basic/filesystem-sets.py filesystem-sets' can be used to view
the generated code.
The check that the kernel doesn't define any new file system magics is
converted into a normal test. It doesn't seem necessary to fail the build
when that happens.
I was looking at strace for systemd-getty-generator and noticed the call to
faccessat2(3</sys>, "", W_OK, AT_EMPTY_PATH), even though we already did
fstatfs(3</sys>), which should give us all the necessary information. Let's
only do this additional check when it's likely to yield something useful, i.e.
for network fses and otherwise skip the syscall.
The call to statvfs is replaced by statfs because that gives us the .f_type
field and allows is_network_fs() to be called.
I'm a bit worried that the is_network_fs() is somewhat costly. This will be
improved in later commits.
Follow-up for 89e83aada8.
`is-supported` expects to return a positive exit status.
To achieve that, verb_make_policy() needs to return 0 on success.
Finishes the fix for #38019.
Co-authored-by: Yu Watanabe <watanabe.yu+github@gmail.com>
Previously, ordered_set_put_strdupv() and friends returns the number of
pushed entries, but that is potentially larger than INT_MAX (of course,
realistically, OOM is triggered in that case).
No caller uses the number of the new entries. Let's return 1 when at
least one element is added.
Fixes CID#1611523.
