My reading is that systemd was just used as an example of the benefit of this change. It could be any software which loads separate parts of glibc and so could run into problems during libc upgrade. Now with this idea of one shared object from musl, the entire system becomes more resilient. systemd is a benefactor but not the only one nor the reason for the change.
> Takes a boolean parameter. If set, a UNIX user and group pair is allocated dynamically when the unit is started, and released as soon as it is stopped. The user and group will not be added to /etc/passwd or /etc/group, but are managed transiently during runtime
Good, this was always incredibly confusing, and a hassle because it even needs Linux-specific code in otherwise completely platform-agnostic (cmake) build system files.
The other even more confusing thing is that -pthread/-lpthread may be needed even when your own code doesn't use pthreads at all (while at it, please also get rid of -pthread), but some dynamically linked dependency does (like linking with X11+GLX+GL) - which then doesn't just cause a linker error but a runtime crash with an entirely unrelated error message (but only on some Linux setups) - I hope the change will fix these problems too.
And hopefully the 'm' library is next (seems they intend to but it didn't make it into this release).
We then added a dummy call to a no-op pthread function, so that users at least get a pthread-related linker error and can figure out that they need the -pthread/-lpthread options instead of running into random runtime problems:
Also, on my Ubuntu laptop this problem didn't happen, that's why I didn't catch it during development, it seems to be specific to some distros or personal config changes.
The affected code bases don't use threading and didn't link pthread before (neither statically nor dynamically).
8 comments
[ 3.0 ms ] story [ 34.4 ms ] threadNSS allows Linux systems to provide custom ways to look up users and groups.
https://en.m.wikipedia.org/wiki/Name_Service_Switch
https://www.man7.org/linux/man-pages/man5/nsswitch.conf.5.ht... says this is implemented by having a shared object library for each "service".
https://www.freedesktop.org/software/systemd/man/nss-systemd... says `nss_systemd` is mainly for systemd's DynamicUser feature.
https://www.freedesktop.org/software/systemd/man/systemd.exe... documents that setting:
> DynamicUser=
> Takes a boolean parameter. If set, a UNIX user and group pair is allocated dynamically when the unit is started, and released as soon as it is stopped. The user and group will not be added to /etc/passwd or /etc/group, but are managed transiently during runtime
https://www.redhat.com/sysadmin/systemd-secure-services explains that this is for sandboxing.
https://www.gnu.org/software/libc/manual/html_node/Name-Serv...
https://www.gnu.org/software/libc/manual/html_node/Adding-an... in particular, which explains how to write a custom NSS service as a shared library.
I expect the concern the article raises applies to all custom NSS services, such as:
- sssd: https://ubuntu.com/server/docs/service-sssd-ad
- nsscache: https://github.com/google/nsscache
The other even more confusing thing is that -pthread/-lpthread may be needed even when your own code doesn't use pthreads at all (while at it, please also get rid of -pthread), but some dynamically linked dependency does (like linking with X11+GLX+GL) - which then doesn't just cause a linker error but a runtime crash with an entirely unrelated error message (but only on some Linux setups) - I hope the change will fix these problems too.
And hopefully the 'm' library is next (seems they intend to but it didn't make it into this release).
Does it only happen when your code links in the static version of a library that requires pthreads?
- https://github.com/floooh/sokol/issues/376
- https://github.com/floooh/sokol/issues/404
- https://github.com/floooh/cimgui-sokol-starterkit/issues/6
We then added a dummy call to a no-op pthread function, so that users at least get a pthread-related linker error and can figure out that they need the -pthread/-lpthread options instead of running into random runtime problems:
- https://github.com/floooh/sokol/pull/456
Also, on my Ubuntu laptop this problem didn't happen, that's why I didn't catch it during development, it seems to be specific to some distros or personal config changes.
The affected code bases don't use threading and didn't link pthread before (neither statically nor dynamically).
Even after this change in glibc, you may still need to use FindThreads to handle [HP-UX][2] (some of which still run [Itanium][3]!!!).
[1]: https://cmake.org/cmake/help/latest/module/FindThreads.html
[2]: https://en.wikipedia.org/wiki/HP-UX
[3]: https://en.wikipedia.org/wiki/Itanium