Some fdopendir() calls remain where safe_close() is manually
performed, those could be simplified as well by converting to
use the _cleanup_close_ machinery, but makes things less trivial
to review so left for a future cleanup.
With the addition of _cleanup_close_ there's a repetitious
pattern of assigning -1 to the fd after a successful fdopen
to prevent its close on cleanup now that the FILE * owns the
fd.
This introduces a wrapper that instead takes a pointer to the
fd being opened, and always overwrites the fd with -1 on success.
A future commit will cleanup all the fdopen call sites to use the
wrapper and elide the manual -1 fd assignment.
/home is posibly a remote file system. it makes sense to order homed
after it, so that we can properly enumerate users in it, but we probably
shouldn't pull it in ourselves, and leave that to users to configure
otherwise.
Fixes: #15102
It's lightweight and generally useful, so it should be enabled by default. But
users might want to disable it for whatever reason, and things should be fine
without it, so let's make it installable so it can be disabled if wanted.
Fixes#15175.
This essentially adds another layer of configurability:
build disable, this, presence of configuration. The default is
set to enabled, because the service does nothing w/o config.
When doing 'make clean', we remove the cached image. So doing
'make -C TEST-NN-foo clean setup run clean-again' in a loop is very slow.
Let's filter out the 'clean' target (if specified), and do the cleaning
in the beginning, and then run other targets in a loop as before.
The test would fail when run again from the same image. So let's
rename the stuff we create to be more unique, and remove it before
running the test. (Removing it after would be more elegant, but it's
hard to make sure that everything is removed when things fail halfway.
Cleanup *before* tests is much more rebust.)
Using s-j-remote fixes the following issue: when coalescing files from multiple
inputs, simply copying all files with into the the same directory might
potentially mess things up, because a newer system.journal might overwrite an
older journal. This happens because we run multiple tests from the same image,
and need to clean out the directory after each run.
By using systemd-journal-remote, we nicely coalesce all files. This has the
advantage that if there aren't too many logs, we end up with just one journal
file.
ARTIFACT_DIRECTORY is for ubuntuautopackagetests, where the journal files are
copied to a separate directory to preserve after tests have been run. This
functionality can now be recreated by setting
ARTIFACT_DIRECTORY=$AUTOPKGTEST_ARTIFACTS.
This was done downstream in debian and ubuntu [1]. I want to change the
downstream file to use run-integration-tests so we can change the way tests
work more easily. Let's start moving downstream functionality upstream.
$ sudo BLACKLIST_MARKERS='blacklist-ubuntu-ci-arm64 blacklist-ubuntu-ci' \
BUILD_DIR=build test/run-integration-tests.sh
[1] https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/tests/upstream
When we are supposed to accept numeric UIDs formatted as string, then
let's check that first, before passing things on to
valid_user_group_name_full(), since that might log about, and not the
other way round.
See: #15201
Follow-up for: 93c23c9297
https://github.com/systemd/systemd/pull/14133 made
capability_ambient_set_apply() acquire capabilities that were explicitly
asked for and drop all others. This change means the function is called
even with an empty capability set, opening up a code path for users
without ambient capabilities to call this function. This function will
error with EINVAL out on kernels < 4.3 because PR_CAP_AMBIENT is not
understood. This turns capability_ambient_set_apply() into a noop for
kernels < 4.3
Fixes https://github.com/systemd/systemd/issues/15225
Functions called from device_setup_unit() already make sure that unit is
enqueued in case it is a new unit or properties exported on the bus have
changed.
This should prevent unnecessary DBus wakeups and associated DBus traffic
when device_setup_unit() was called while reparsing /proc/self/mountinfo
due to the mountinfo notifications. Note that we parse
/proc/self/mountinfo quite often on the busy systems (e.g. k8s container
hosts) but majority of the time mounts didn't change, only some mount
got added. Thus we don't need to generate PropertiesChanged for devices
associated with the mounts that didn't change.
Thanks to Renaud Métrich <rmetrich@redhat.com> for debugging the
problem and providing draft version of the patch.
I put the helper functions in a separate header file, because they don't fit
anywhere else. pthread_mutex_{lock,unlock} is used in two places: nss-systemd
and hashmap. I don't indent to convert hashmap to use the helpers, because
there it'd make the code more complicated. Is it worth to create a new header
file even if the only use is in nss-systemd.c? I think yes, because it feels
clean and also I think it's likely that pthread_mutex_{lock,unlock} will be
used in other places later.
Vito Caputo