The commit 01e8f570c6 unpinned the
LLVM version, which led to the following warnings whenever Scudo
is loaded (basically whenever a command is started when used
system-wide):
Scudo WARNING: found 3 unrecognized flag(s):
DeleteSizeMismatch=0:DeallocationTypeMismatch=0
DeallocationTypeMismatch=0
ZeroContents=1
According to the current Scudo documentation [1] the options are
now spelled differently. This commit keeps all existing options
and only updates the spelling.
[1] https://llvm.org/docs/ScudoHardenedAllocator.html
Reported-by: CUB3D <callumthom11@gmail.com>
The commit 01e8f570c6 unpinned the
LLVM version, which led to building errors similar to this when
Scudo is used:
building the system configuration...
error: builder for '/nix/store/1f9z73haq6avvv19glifalfnmpw3gsbx-malloc-provider-scudo.drv' failed with exit code 1;
last 1 log lines:
> cp: cannot stat '/nix/store/s43991isxhvknqmk53q7pqmkdrfvj1p4-compiler-rt-libc-19.1.7/lib/linux/libclang_rt.scudo-x86_64.so': No such file or directory
For full logs, run:
nix log /nix/store/1f9z73haq6avvv19glifalfnmpw3gsbx-malloc-provider-scudo.drv
It seems in the new LLVM version the Scudo library was moved:
$ ls /nix/store/*-compiler-rt-libc-20.1.8/lib/linux/libclang_rt.scudo*
/nix/store/z98mwyi0w8f4kgk3rw6av946azh28hc9-compiler-rt-libc-20.1.8/lib/linux/libclang_rt.scudo_standalone_cxx-x86_64.a
/nix/store/z98mwyi0w8f4kgk3rw6av946azh28hc9-compiler-rt-libc-20.1.8/lib/linux/libclang_rt.scudo_standalone-x86_64.a
/nix/store/z98mwyi0w8f4kgk3rw6av946azh28hc9-compiler-rt-libc-20.1.8/lib/linux/libclang_rt.scudo_standalone-x86_64.so
This commit adjusts the library path.
Co-authored-by: CUB3D <callumthom11@gmail.com>
To re-execute a systemd manager interface, the
current switch-to-configuration-ng code calls the
org.freedesktop.systemd1.Manager.Reexecute method on D-Bus.
As noted in a comment, the systemd manager does not reply to that
method call (it has the org.freedesktop.DBus.Method.NoReply attribute).
Instead, to signal when it is done re-executing, it passes its old D-Bus
connection socket to the new systemd manager and once the new systemd
manager is ready to receive D-Bus messages on the new D-Bus connection
socket, it will close the old connection socket. As the old connection
socket is closed, the D-Bus daemon assigns the org.freedesktop.systemd1
bus name to the new D-Bus connection [1].
The dbus-codegen crate does not support the
org.freedesktop.DBus.Method.NoReply attribute. What currently
happens in switch-to-configuration-ng is that it blocks until the
old connection socket is closed which makes the D-Bus daemon send a
org.freedesktop.DBus.Error.NoReply error to switch-to-configuration-ng
which then unblocks it.
If the systemd manager takes a long time to re-execute (more than 10
seconds), then the method call can also timeout which means that
switch-to-configuration-ng will proceed with the next systemd manager
method calls, leading to the following error:
> Error: Failed to restart nixos-activation.service
>
> Caused by:
> Message recipient disconnected from message bus without replying
This was observed on a server with a very large number of
filesystem mounts that make re-execution take more than 10
seconds.
Use the org.freedesktop.DBus.NameOwnerChanged signal [2] to determine
when systemd is done reexecuting and is ready to receive new D-Bus
messages again.
[1]: https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-overview
[2]: https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-name-owner-changed
