i.e. let's pick some files we know are too large, or where struct stat's
.st_size is zero even though non-empty, and test read_virtual_file()
with that, to ensure things are handled sensibly. Goal is to ensure all
three major codepaths in read_virtual_file() are tested.
Prompted-by: #20743
Previously, if a unit file which contains n IPAddressAllow/Deny= lines,
then the computational order of parsing the file was O(n^3), as
ip_address_access_reduce(), whose order is O(n^2), is called for each line.
By replacing in_addr_prefix related functions, now the computational
order is O(n log n).
Fixes#20680.
In some cases it's useful to explicitly generate the JSON field names to
generate for table columns, instead of auto-mangling them from table
header names that are intended for human consumption.
This adds the infra and a test for it.
It's intended to be used by #20544, for the first column, which in text
mode should have an empty header field, but have an explicit name in
json output mode.
The helper call rounds up to next multiple of specified boundary. If one
passes a very large value as first argument, then there might not be a
next multiple. So far we ignored that. Let's handle this now and return
SIZE_MAX in this case, as special indicator that we reached the end.
Of course, IRL this should not happen. With this new change we at least
do something somewhat reasonable, leaving it to the caller to handle it
further.
According to Coverity, 194 ouf of 227 times we check for snprintf return code.
Voidify the rest.
CID#1461512
CID#1461513
CID#1461514
CID#1461515
CID#1461516
CID#1461518
CID#1461519
CID#1461520
CID#1461522
This adds a bit of generic helper tools for installing files/dir trees.
"installing" is supposed to mean the final step when preparing a disk
image or directory tree, where the result is renamed to its final name.
It has some bells and whistles, as it is able to replace existing files
sanely, can fsync() things carefully and can mark things read-only in a
nice way.
This is supposed to be generic, unified code that can be used eventually
for any of our tools that prepare disk images/directory trees, including
importd, nspawn's --template= mechanism, the discover-image.c logic,
and more.
When the root parameter in find_executable_full is set, chase_symlinks prefixes this root
to every check of the path name to find the complete path of the execuatble in case the
path provided is not absolute. This is only done for the non NULL root because otherwise
the chase_symlinks function would alter the behavior of some of the callers which would
in turn alter the outputs in a way that is undesirable. The find_execuatble_full function is
invoked by the verify_executable function in analyze-verify.
-------------------------------------------------------------------------------
Example Run:
foobar.service created below is a service unit file that has a non-existing key-value
pairing (foo = bar) and is thus, syntactically invalid.
maanya-goenka@debian:~/systemd (img-support)$ cat <<EOF>img/usr/lib/systemd/system/foobar.service
> [Unit]
> foo = bar
>
> [Service]
> ExecStart = /opt/script0.sh
> EOF
The failure to create foobar.service because of the recursive dependency searching and verification has been addressed
in a different PR: systemd-analyze: add option to return an error value when unit verification fails #20233
maanya-goenka@debian:~/systemd (img-support)$ sudo build/systemd-analyze verify --root=img/ foobar.service
/home/maanya-goenka/systemd/img/usr/lib/systemd/system/foobar.service:2: Unknown key name 'foo' in section 'Unit', ignoring.
foobar.service: Failed to create foobar.service/start: Unit sysinit.target not found.
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
DISKSEQ is a reliable way to find out if we missed a uevent or not, as
it's monotonically increasing. If we parse an event with a smaller or
no sequence number, we know we need to wait longer. If we parse an
event with a greater sequence number, we know we missed it and the
device was reused.
As documented in /meson.build where the variable is defined,
meson.build_root() doesn't work as expected with project nesting. I have
no idea why anyone would want to embed systemd in another meson project,
but let's use the variable if we have it.