What appears to be going on here is that systemd is not restarted as part of the upgrade of glibc so it is still running glibc 2.33. When starting a service that does anything even slightly funky with users and groups (so things that use DynamicUser= like systemd-resolved but also things like docker which just uses Group= on a socket) it forks itself and calls Name Service Switch apis which dlopen nss modules like /lib/x86_64-linux-gnu/libnss_files.so.2. But these now come from the glibc 2.34 package and are not compatible with the libc already loaded into the forked process and so the nss calls all fail.
I don't know why this didn't bite us for other glibc upgrades -- nss modules are basically never cross version compatible afaik. Maybe systemd has changed and used to have an execve between the fork and any access to nss apis?
What appears to be going on here is that systemd is not restarted as part of the upgrade of glibc so it is still running glibc 2.33. When starting a service that does anything even slightly funky with users and groups (so things that use DynamicUser= like systemd-resolved but also things like docker which just uses Group= on a socket) it forks itself and calls Name Service Switch apis which dlopen nss modules like /lib/x86_ 64-linux- gnu/libnss_ files.so. 2. But these now come from the glibc 2.34 package and are not compatible with the libc already loaded into the forked process and so the nss calls all fail.
I don't know why this didn't bite us for other glibc upgrades -- nss modules are basically never cross version compatible afaik. Maybe systemd has changed and used to have an execve between the fork and any access to nss apis?