Follow-up for d120ce478d
blockdev@.target is used as a synchronization point between
the mount unit and corresponding systemd-cryptsetup@.service.
After the mentioned commit, it doesn't get a stop job enqueued
during shutdown, and thus the stop job for systemd-cryptsetup@.service
could be run before the mount unit is stopped.
Therefore, let's make blockdev@.target conflict with umount.target,
which is also what systemd-cryptsetup@.service does.
Fixes#29336
This also adds an ignore list, which currently contains the whole API as of
version 250, since that's the base we used for dbus interfaces.
See d9d2d16aea
Build targets should have a link dependency on the version scripts they
use. This also uses absolute paths in anticipation for meson 1.3
needlessly deprecating file to string conversions.
...
uint8_t c;
struct trie_node *child;
for (p = 0; (c = trie->strings->buf[node->prefix_off + p]); p++) {
_cleanup_free_ struct trie_node *new_child = NULL;
_cleanup_free_ char *s = NULL;
ssize_t off;
if (c == search[i + p])
continue;
...
When '®' is present in search, c is 194, search[i + p] is -62, c is not equal to search[i + p], but c should be equal to search[i + p].
We might need a lot of fds on large systems, hence raise RLIMIT_NOFILE
to what the service manager allows us, which is quite a lot these days.
udev already sets FORK_RLIMIT_NOFILE_SAFE when forking of chilren, thus
ensuring that forked off processes get their RLIMIT_NOFILE soft limit
reset to 1K for compat with crappy old select().
Replaces: #29298Fixes: #28583
service_restart_usec_next() is also called when querying
'RestartUSecNext' dbus property. Let's avoid the redundant
logging triggered every time user does a 'systemctl status'.
So, unfortunately oomd uses "io.system." rather than "io.systemd." as
prefix for its sockets. This is a mistake, and doesn't match the
Varlink interface naming or anything else in oomd.
hence, let's fix that.
Given that this is an internal protocol between PID1 and oomd let's
simply change this without retaining compat.
Let's move setting of O_NONBLOCK into varlink_server_listen_fd() and out
of varlink_server_create_listen_fd_socket(). The latter has two callers:
varlink_server_listen_fd() and varlink_server_listen_address(), which
guarantees O_CLOEXEC+O_NONBLOCK anyway, hence no neet to repeat the
logic.
The tool initially just measured the boot phase, but was subsequently
extended to measure file system and machine IDs, too. At AllSystemsGo
there were request to add more, and make the tool generically
accessible.
Hence, let's rename the binary (but not the pcrphase services), to make
clear the tool is not just measureing the boot phase, but a lot of other
things too.
The tool is located in /usr/lib/ and still relatively new, hence let's
just rename the binary and be done with it, while keeping the unit names
stable.
While we are at it, also move the tool out of src/boot/ and into its own
src/pcrextend/ dir, since it's not really doing boot related stuff
anymore.
Latest mkosi sets $MKOSI_UID and $MKOSI_GID to the uid/gid of the
user running mkosi. Let's make use of this to run meson setup and
ninja as the user running mkosi, so that if we execute git as a
subprocess during meson setup, it doesn't complain about unsafe
directories. This also makes sure all the build artifacts are owned
on the host by the user running mkosi.
This commit adds hwdb entry for Miglia Technology Harmony Audio (HA02).
The device is an application of OXford Semiconductor FW970 and will be
supported by ALSA oxfw driver in future.
On slower/overloaded systems it may take a bit for the swtpm socket
to show up:
I: Started swtpm as PID 189419 with state dir /tmp/tmp.pWqUutuGUj
I: Configured emulated TPM2 device tpm-spapr
+ tee /var/tmp/systemd-test-TEST-70-TPM2_1/console.log
+ timeout --foreground 1200 /bin/qemu-system-ppc64le -smp 4 ...
qemu-system-ppc64le: -chardev socket,id=chrtpm,path=/tmp/tmp.pWqUutuGUj/sock: Failed to connect to '/tmp/tmp.pWqUutuGUj/sock': No such file or directory
E: qemu failed with exit code 1
Spotted regularly in the ppc64le cron job and in some Ubuntu CI/CentOS CI
pr runs [0].
[0] https://github.com/systemd/systemd/pull/29183#issuecomment-1721727927
We can't do anything about them anyway, and most importantly this seems
to alleviate systemd/systemd-centos-ci#660, which should make the CIs
a bit less angry (at least until the issue is addressed properly).
