It seems to, but I was a bit incredulous… The comment is adjusted to match
the standard.
The trick with a temporary buffer is neat. I wasn't sure if it is valid, but
the standard says so. The test really tests that we are reading the rules right
and that the compiler doesn't do anythign strange or emit an unexpected
warning.
Let's make sure we signal out-of-band via an error message if a process
doesn't have a parent process whose PID we could return. Otherwise we'll
too likely hide errors, as we return an invalid PID 0, which in other
contexts has special meaning (i.e. usually "myself").
Replaces: #20153
This is based on work by @dtardon, but goes a different route, by
ensuring we propagate a proper error in this case.
This modernizes the function in question a bit in other ways, i.e.
renames stuff and makes the return parameter optional.
Fixes#20089. This is essentially a packaging bug in CentOS: the
db lists a timezone which is not present in /usr/share/zoneinfo.
Let's skip this gracefully.
Add ip protocol token to SocketBind{Allow|Deny}= property parser.
Use parse_socket_bind_item helper.
Replace int32_t with int in cgroup item for socket-bind as it was
requested in [0].
Update tests.
[0] https://github.com/systemd/systemd/pull/19942#discussion_r652150024
Parse address family, ip protocol and ports, any of them can be
optional. If neither is specified, a special value 'any' is expected.
Helper is placed in shared to be reused in both fragment and dbus.
Add unit tests with valid and invalid examples.
This fixes repart's, systemctl's, sysusers' and tmpfiles' specifier
expansion to honour the root dir specified with --root=. This is
relevant for specifiers such as %m, %o, … which are directly sourced
from files on disk.
This doesn't try to be overly smart: specifiers referring to runtime
concepts (i.e. boot ID, architecture, hostname) rather than files on the
medium are left as is. There's certainly a point to be made that they
should fail in case --root= is specified, but I am not entirely convinced
about that, and it's certainly something we can look into later if
there's reason to.
I wondered for a while how to hook this up best, but given that quite a
large number of specifiers resolve to data from files on disks, and most
of our tools needs this, I ultimately decided to make the root dir a
first class parameter to specifier_printf().
Replaces: #16187Fixes: #16183
The goal is to move everything that requires selinux or smack
away from src/basic/. This means that src/basic/label.[ch] must move,
which implies btrfs-util.[ch], copy.[ch], and a bunch of other files
which form a cluster of internal use.
This is just moving text around, so there should be no functional difference.
test-blockdev-util is new, because path_is_encrypted() is moved to
blockdev-util.c, and so far we didn't have any tests for code there.
fd_duplicate_data_fd() is renamed to copy_data_fd(). This makes
the two functions have nicely similar names.
Now fd-util.[ch] is again about low-level file descriptor manipulations.
copy_data_fd() is a complex function that internally wraps the other
functions in copy.c. I want to move copy.c and the whole cluster of
related code from basic/ to shared/ later on, and this is a preparatory
step for that.
format_timestamp_relative currently returns the plural form of
years and months no matter the quantity, and in many cases (for
durations > 1 week) this is the same with days.
This patch changes this so that the function takes the quantity into account,
returning "1 month 1 week ago" instead of "1 months 1 weeks ago".
I wanted to see what is_path_read_only_fs() and is_path_temporary_fs() return
in a chroot, and various tests would fail. For most of our codebase, we can
assume that /proc and such are mounted, and it doesn't make sense to make the
tests work in a chroot. But let's do it here. (In general, it would be useful
for most stuff in src/basic/, since it's linked into libraries which might be
invoked in incorrectly set up environments and should not fail too badly.)
Since those workarounds have been added, work has been done to tighten
up log_*() return values. Seems we get no warning with
gcc-11.1.1-1.fc34.x86_64 and -O0/-O2.
