This was broken in a subtle way: we'd get an ELF ref, but not the right one,
so no metadata note would be found.
Change the parsing function to return 1 when it finds something, so that
we can return early only when that happens.
It seems that `pam_systemd` was the only thing left that wanted to use sockets
in file system path `/tmp/.X11-unix/X*`. X11 apps actually prefer using the
abstract socket version.
This allows running Xserver with `-nolisten tcp -nolisten unix`, which makes
the server only listen to an abstract socket.
Also in my setup, Xserver is running as a separate system service instead of
starting from display manager service, and now `PrivateTmp=yes` can be used for
both. The file system of the display manager service is inherited by user apps
and now their `/tmp` will be separate from `/tmp` of PID1 namespace as well as
`/tmp` of Xserver.
In case `/proc` is successfully mounted with pid tree subset only due to
`ProcSubset=pid`, the protective mounts for `ProtectKernelTunables=yes` and
`ProtectKernelLogs=yes` to non-pid `/proc` paths are failing because the paths
don't exist. But the pid only option may have failed gracefully (for example
because of ancient kernel), so let's try the mounts but it's not fatal if they
don't succeed.
00db9a114e ("docs: generate table from header using a script") got the
descriptions for the partition types mixed up. After that change, the
spec claimed, for example, that the /usr partition should contain
"dm-verity integrity hash data for the matching root partition", and
that the /usr verity partition should be of type "Any native, optionally
in LUKS". This made the spec an extremely confusing read before I
figured out what must have happened!
I've gone through the table as it existed prior to 00db9a114e, and moved
the descriptions around in the script that generates the table until
they matched up with what they used to be. Then I regenerated the
table from the fixed script.
I think the function name is confusing: we generally say "free_free" when
both keys and values are freed in a hash map, but here the type is an
array of strvs, so the name should be something like strv_array_free.
The function is unused since 143fadf369 (2018),
let's just drop it.
Make oomctl a bit less likely to race with systemd-oomd receiving the
managed oom cgroup info by checking oomctl output in a loop with
timeout.
Fixes#21146
We would fail if the input file was corrupted:
build/test-journal-flush ./system@0005b7dac334f805-0021aca076ae5c5e.journal\~
journal_file_copy_entry failed: Bad message
Assertion 'r >= 0' failed at src/libsystemd/sd-journal/test-journal-flush.c:55, function main(). Aborting.
[1] 619472 IOT instruction (core dumped) build/test-journal-flush ./system@0005b7dac334f805-0021aca076ae5c5e.journal\~
Let's skip some "reasonable" errors.
Fixes#17963.
Code simplification; no idea why the Context structs were being
heap-allocated piecemeal. There aren't many and they're small,
and made even smaller with this commit.
This also gets rid of the Context.cache backreference by just
accompanying the Context* with MMapCache* to the few private
Context* operations, resolving the context ID to a Context* at
the single public entrypoint: mmap_cache_fd_get(), which asserts
on the value being within bounds. The Context.id member and
checks are also removed, as there's far less opportunity for
these things to become inconsistent now.
Of course this drops all context_{add,free}() related code,
making for a tasty diffstat.
If the iovec contains the same data more than once, we'll end up with
duplicate offsets in the items array. Let's make sure we remove any
duplicates before we store the items in an entry object.
The LIST_REMOVE() macro always assigns NULL to w->unused_prev,
meaning every time this window was in last_unused, the remainder
of the unused list was lost to the ether.
Turns out there's been a memory leak in journald after all, this
code has been there since at least 2013...
The test was changed at @bluca 's request to avoid sleeps,
but the change insufficient to avoid all races.
The kill command is now run from the script itself to avoid using
ExecStartPost
This actually causes mismatches between the header tail entry seqnum
and the last entry seqnum since when we revert the header seqnum, we
don't remove the entry object we added. If adding the entry object
itself fails, we don't need to revert the seqnum since it's never
incremented so let's remove this logic alltogether.
All our D-Bus services support the LogControl1 API, but homed didn't so
far. Fix that, and make use of it in the test case, to make debugging it
easier.
Luca Boccassi
Topi Miettinen
Yu Watanabe
Alyssa Ross
Frantisek Sumsal
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Anita Zhang
Vito Caputo
Daan De Meyer
Henri Chain