For the other verbs turning off JSON mode makes sense, but for "call"
not so much, after all the contents of a method call reply is JSON we
couldn't really show any other way.
Hence, when JSON output was not configured otherwise in "call", default
to the same as -j.
It exposes the varlink_collect() call we internally provide: it collects
all responses of a method call that is issued with the "more" method
call flag. It then returns the result as a single JSON array.
This reworks varlink_collect() so that it is not just a wrapper around
varlink_observe(), varlink_bind_reply() and others. It becomes a first
class operation.
This has various benefits:
1. Memory management is normalized: the reply json variant is now
tracked as part of the varlink object, and thus we do not pass
ownership to the caller. This is just like we do it for simple method
calls and removes a lot of confusion.
2. The bind reply/user data pointer can be used for user stuff, we'll
not silently override this.
3. We enforce an overall time-out operation on the whole thing, so that
this synchronous operation does no longer block forever.
As described in #30940, systemd-firstboot currently does not perform
any validation on keymap entry, allowing nonexistent keymaps to be
written to /etc/vconsole.conf. This commit adds validation checks
based on those already performed on locale entry, preventing invalid
keymaps from being set.
Closes#30940
m
Previously, get_display_timestamp() is unconditionally called even if we
will show logs in e.g. json format.
This drops unnecessary call of get_display_timestamp().
This also makes journal fields in each entry parsed only once in
output_short(). Still output_verbose() twice though.
This should improve performance of dumping journals.
Replaces #29365.
Co-authored-by: Costa Tsaousis <costa@netdata.cloud>
When the offset of the last entry object (or last object for journal
files generated by an old journald) is not changed, the timestamps
should be updated by journal_file_read_tail_timestamp() are unchanged.
So, we can drop to call fstat() in the function.
As, the journal header is always mapped, so we can read the offset and
journal file state without calling fstat.
Still, when the last entry offset is changed, we may need to call fstat()
to read the entry object. But, hopefully the number of fstat() call
can be reduced.
The latest Rawhide compose (20240210.n.1) finished successfully and made
it to the mirrors, so let's drop the bpftool workaround.
This reverts commit 8a0ec8852c.
I think this was just overlooked in #13754, which removed
the restriction of Restart= on Type=oneshot services.
There's no reason to prevent RestartForceExitStatus=
now that Restart= has been allowed.
Closes#31148
This was discussed in
https://github.com/systemd/systemd/pull/13754#discussion_r333395362.
I think we should actually list "success" Restart= settings instead.
There are more error statuses than success ones after all, and this
list hasn't really changed for quite some time.
These can be used along with two new settings MountPoint= and
EncryptedVolume= to write fstab and crypttab entries to the given
paths respectively in the root directory that repart is operating on.
This is useful to cover scenarios that aren't covered by the
Discoverable Partitions Spec. For example when one wants to mount
/home as a separate btrfs subvolume. Because multiple btrfs subvolumes
can be mounted from the same partition, we allow specifying MountPoint=
multiple times to add multiple entries for the same partition.
When we're running with sanitizers, sd-executor might pull in a
significant chunk of shared libraries on startup, that can cause a lot
of memory pressure and put us in the front when sd-oomd decides to go on
a killing spree. This is exacerbated further on Arch Linux when built
with gcc, as Arch ships unstripped gcc-libs so sd-executor pulls in over
30M of additional shared libs on startup:
~# lddtree build-san/systemd-executor
build-san/systemd-executor (interpreter => /lib64/ld-linux-x86-64.so.2)
libasan.so.8 => /usr/lib/libasan.so.8
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.6 => /usr/lib/libm.so.6
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libsystemd-core-255.so => /root/systemd/build-san/src/core/libsystemd-core-255.so
libaudit.so.1 => /usr/lib/libaudit.so.1
libcap-ng.so.0 => /usr/lib/libcap-ng.so.0
...
libseccomp.so.2 => /usr/lib/libseccomp.so.2
libubsan.so.1 => /usr/lib/libubsan.so.1
libc.so.6 => /usr/lib/libc.so.6
~# ls -Llh /usr/lib/libasan.so.8 /usr/lib/libstdc++.so.6 /usr/lib/libubsan.so.1
-rwxr-xr-x 1 root root 9.7M Feb 2 10:36 /usr/lib/libasan.so.8
-rwxr-xr-x 1 root root 21M Feb 2 10:36 /usr/lib/libstdc++.so.6
-rwxr-xr-x 1 root root 3.2M Feb 2 10:36 /usr/lib/libubsan.so.1
Sanitized libsystemd-core.so is also quite big:
~# ls -Llh /root/systemd/build-san/src/core/libsystemd-core-255.so /usr/lib/systemd/libsystemd-core-255.so
-rwxr-xr-x 1 root root 26M Feb 8 19:04 /root/systemd/build-san/src/core/libsystemd-core-255.so
-rwxr-xr-x 1 root root 5.9M Feb 7 12:03 /usr/lib/systemd/libsystemd-core-255.so
In journal_file_next_entry(), if the passed offset matches an entry object,
then generic_array_bisect() returns the object, but the object we
requested is the next (or previous) object. Hence, we should not validate
the object returned by generic_array_bisect(), otherwise it may fail
when the journal is corrupted.
Note the validity of the entry object that should be returned by
journal_file_next_entry() will be checked in the following generic_array_get().
So, when journal_file_next_entry() succeeds, the returned object is
always validated.
Let's consider the case that
- the first array contains valid entries,
- all entries in the second array are corrupted.
Then, when we are going to upwards, and a call of generic_array_bisect()
matches the last entry of the first array, then the second array was
cached with last_index == UINT64_MAX, instead of the first array with
its last entry.
Hence, when generic_array_bisect() is called next time, the function call
of test() always fail. So, the cache entry is mostly meaningless.
Let's always store valid cache entry.
The provider API which is new requires providers, which are not
widely available and don't work very well yet, so also use a
fallback with the legacy engine API.
Currently in many of our test cases you'll see a warning about a tun
device not being around. Let's make that quiet, since if there's no such
device there's no point in adding it to a policy anyway, and it makes
useless noise go away.
We keep the warning as a warning if a device node is missing for other
errors than ENOENT.
under some conditions we suppress generating BPF programs. Let's
systematically return 0 when we do this, and 1 if we did actually
soething, instead of second guessing this in the caller.
This is not only more correct, but allows us to suppress BPF programs in
more cases in later commits.
Lennart Poettering
Yu Watanabe
Eric Daigle
Frantisek Sumsal
Mike Yuan
Daan De Meyer
Luca Boccassi
dependabot[bot]