Also, while we are at it, beef it up, by adding json-seq support (i.e.
https://tools.ietf.org/html/rfc7464). This is particularly useful in
conjunction with jq's --seq switch.
This broke the compilation for coverity under travis. Our build script does
something like this:
$ CFLAGS='-D_Float128=long\ double -D_Float64=double -D_Float64x=long\ double -D_Float32=float -D_Float32x=double' meson cov-build -Dman=false
$ ninja -C build
...
[pid 27096] execve("/usr/bin/cc", ["/usr/bin/cc", "-D_Float128=long", "double", "-D_Float64=double", "-D_Float64x=long", "double", "-D_Float32=float", "-D_Float32x=double", "-E", "-dM", "-include", "linux/capability.h", "-include", "config.h", "-include", "../src/basic/missing.h", "-"], 0x55ab75ea4e80 /* 91 vars */) = 0
cc: error: double: No such file or directory
cc: error: double: No such file or directory
[pid 27096] +++ exited with 1 +++
I'm sure this could be fixed somehow, but since the original motivation for 56f56d5ad856d9bd1070693490b210e0a0ccde92 wasn't very strong, let's just revert
it as this seems to be the simplest solution.
manager: simplify error handling in manager_deserialize()
If a memory error occurred, we would still go through the path which sets the
error on ferror(). It is unlikely that ferror() returns true, but it's seems
cleaner to just propagate the error we already have.
The handling of fgets() returning NULL is also simplified: according to the man
page, it returns NULL only on EOF or error. So if feof() returns true, I don't
think we should call ferror() again.
While at it, let's set errno to 0 and check that it is set before returning it
as an error. The man pages for fgets() and feof() do not say anything about
setting errno.
manager: also use the reloading "cleanup" function in manager_startup
Here the behaviour is nominally changed, because we will decrease the
counter on error. But the only caller quits the program if error occurs,
so this makes no practical difference.
A new switch "-j" or "--json=" is added which transforms dbus
marshalling into json. This is extremely useful in combination with
tools such as "jq" to process bus calls further.
https://github.com/mesonbuild/meson/issues/1644 was resolved in 0.42:
https://github.com/mesonbuild/meson/pull/2191/commits/be4428005dff8b17af5696c8f05567de9af1a8c5,
but still no-go.
By default, UBSan neither crashes nor exits with a non-zero exit code
when undefined behavior has been detected. This is problematic because
it makes it much harder to catch issues like https://github.com/systemd/systemd/issues/10346,
https://github.com/systemd/systemd/issues/10347, and https://github.com/systemd/systemd/issues/10333.
In fact, those issue were found just because I decided to grep
the test log, which isn't something that I normally do :-)
As it turns out, the only way to make UBSan signal that something is wrong that works more or less
reliably everywhere is to pass halt_on_error=1 (though, it's probably worth noting that it's currently
not set for PID1 in order not to trigger kernel panics).
See https://reviews.llvm.org/D35085#804183 and https://chromium.googlesource.com/chromium/src/testing/libfuzzer/+/HEAD/reference.md
linux/capability.h's CAP_TO_MASK potentially shifts a signed int "1"
(i.e. 32bit wide) left by 31 which means it becomes negative. That's
just weird, and ubsan complains about it. Let's introduce our own macro
CAP_TO_MASK_CORRECTED which doesn't fall into this trap, and make use of
it.
core: include environment generator runtime in generator timestamps
Currently they aren't covered and it probably isn't worth adding another
kind of timestamp just for this, hence simply include it in the regular
generator timestamps.
core: rework how we set the objective to MANAGER_OK
Let's do so already when we are about to complete startup/reload, so
that manager_catchup() is run in a context where MANAGER_IS_RUNNING()
returns true, as the intention is.
core: bring manager_startup() and manager_reload() more inline
Both functions do partly the same, let's make sure they do it in the
same order, and that we don't miss some calls.
This makes a number of changes:
1. Moves exec_runtime_vacuum() two calls down in manager_startup(). This
should not have any effect but makes manager_startup() more like
manager_reload().
2. Calls manager_recheck_journal(), manager_recheck_dbus(),
manager_enqueue_sync_bus_names() in manager_startup() too. This is a
good idea since during reeexec we pass through manager_startup() and
hence can't assume dbus and journald weren't up yet, hence let's
check if they are ready to be connected to.
3. Include manager_enumerate_perpetual() in manager_reload(), too. This
is not strictly necessary, since these units are included in the
serialization anyway, but it's still a nice thing, in particular as
theoretically the deserialization could fail.
manager: rework error handling and logging in manager_reload()
let's clean up error handling and logging in manager_reload() a bit.
Specifically: make sure we log about every error we might encounter at
least and at most once.
When we encounter an error before the "point of no return" then log at
LOG_ERR about it and propagate it. Otherwise, eat it up, but warn about
it and proceed, it's the best we can do.
If manager_serialize() fails in the middle (which it hopefully doesn't)
make sure to fix up m->n_reloading correctly again so that we don't
leave it > 0 when it really shouldn't be.
Let's make them typesafe, and let's add a nice macro helper for checking
if we are in a test run, which should make testing for this much easier
to read for most cases.
core: tiny tweak for cgroup trimming during manager_free()
Instead of blacklisting when not to trim the cgroup tree, let's instead
whitelist when to do it, as an excercise of being careful when being
destructive.
This should not change behaviour with exception that during switch roots
we now won't attempt to trim the cgroup tree anymore. Which is more
correct behaviour after all we serialize/deserialize during the
transition and should be needlessly destructive.
"ExitCode" is a bit of a misnomer in two ways: it suggests this was
about the "exit code" concept that exit()/waitid() deal with, but really
isn't. Moreover, it's not event just about exiting either, but more
often about reloading/reexecing or rebooting. Let's hence pick a new
name for this that is a bit more correct.
I initially thought about naming this the "state", but that'd be a
misnomer too, as the value really encodes a "goal" more than a current
state. Also we already have the externally visible ManagerState.
projects / thirdparty / systemd.git / log
