New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
systemd-resolved.service: Couldn't add UID/GID reference to unit, proceeding without: Device or resource busy #9702
Comments
This has since been fixed by #9586, which creates the users statically and sets permissions of the runtime directories accordingly, even though DynamicUser still ships as "yes" for these units... It's safe to turn them off now, I'm doing that on Fedora due to another issue with SELinux compatibility... Cheers, |
@filbranden Thank you very much for your quick advice! |
No, this issue is not fixed. With a statically allocated user this error message should not show up. |
@filbranden why? Using |
BTW, I have not seen this message. Is this shown only when selinux is enabled? |
@yuwata For my case, selinux is disabled and apparmor is enabled, as it is recent debian default. Kernel is 4.17.0-1-amd64. |
@ryutaroh-matsumoto The message is shown even when AppArmor is disabled? |
@yuwata I don't have access to the machine running Debian unstable as it is in my home. I will see and answer it, probably midnight today (Japanese time). |
@yuwata I can reproduce the problem in a pristine Debian buster qemu VM. SELinux is not enabled, disabling AppArmor makes no difference |
Interestingly, this only happens for resolved. timesyncd and networkd (which also have a statically allocated system user and |
@yuwata I observed the strange log. Firstly, the following is
The following is the output of
|
|
I think the "Device or resource busy" (which translates from errno EBUSY) is coming from here. But I haven't really digged down into the code to understand why it needs to retry too many times... |
Changing the gid of |
Yeah, there's definitely a bug in there... I was looking at the code but unsure what might be causing it. I'll try to reproduce it locally and add more traces to help do so. Cheers, |
Hmm... Still I cannot reproduce this. I've tried to create static systemd-resolve user and group with different UID/GID. @ryutaroh-matsumoto Could you provide the unit file of systemd-resolved.service? I.e. please paste the result of |
My guess is to reproduce this you also need the GID matching the original UID to result in a valid group... In @ryutaroh-matsumoto's example, GID 102 was allocated by systemd-network... So |
@filbranden Hmm.
But still I cannot reproduce this... |
@yuwata yes, I will. But please wait for a while as I am not in my home now... With the original passwd, systemd-resolve has uid 102 gid 103. The group has systemd-resolve as 103 and systemd-networkd as 102 as pointed out by @filbranden |
|
Maybe try There's two log lines with |
Oh, finally, I reproduce this. Adding |
Hmm. So, the problem is that only UID is stored in the storage socket... |
When DynamicUser=yes and static User= are set, and the user has different uid and gid, then as the storage socket for the dynamic user does not contains gid, we need to obtain gid. Fixes systemd#9702.
Fix is waiting in #9720. |
When DynamicUser=yes and static User= are set, and the user has different uid and gid, then as the storage socket for the dynamic user does not contains gid, we need to obtain gid. Follow-up for 9ec655c. Fixes systemd#9702.
When DynamicUser=yes and static User= are set, and the user has different uid and gid, then as the storage socket for the dynamic user does not contains gid, we need to obtain gid. Follow-up for 9ec655c. Fixes systemd#9702. (cherry picked from commit 25a1df7)
When DynamicUser=yes and static User= are set, and the user has different uid and gid, then as the storage socket for the dynamic user does not contains gid, we need to obtain gid. Follow-up for 9ec655c. Fixes systemd#9702. (cherry picked from commit 25a1df7)
systemd version the issue has been seen with
239-7 in Debian unstable.
Used distribution
Debian unstable. I filed a bug report to the downstream as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904335,
and I was suggested there reporting to the upstream.
Expected behaviour you didn't see
We don't see
systemd[1]: systemd-resolved.service: Couldn't add UID/GID reference to unit, proceeding without: Device or resource busy
Unexpected behaviour you saw
The static user
systemd-resolve
in/etc/passwd
andDynamicUser=yes
give the following journal log.Changing
DynamicUser=yes
toDynamicUser=no
fixes the problem.To the down stream bug report, @mbiebl wrote:
Steps to reproduce the problem
See above.
The text was updated successfully, but these errors were encountered: