Systemd-resolved.service: Failed to determine user credentials: No such process

Project Discussion
1

Fedora CoreOS 34.20210904.3.0

# systemctl status systemd-resolved.service 
× systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2021-09-23 05:52:00 UTC; 1min 30s ago

# journalctl -xeu systemd-resolved.service 

Sep 23 06:32:11 fcostest systemd[832]: systemd-resolved.service: Failed to determine user credentials: No such process
Sep 23 06:32:11 fcostest systemd[832]: systemd-resolved.service: Failed at step USER spawning /usr/lib/systemd/systemd-resolved: No such process

# systemctl cat systemd-resolved.service | grep User

**User** =systemd-resolve

# id -u systemd-resolve

id: ‘systemd-resolve’: no such user
2

I’m not seeing this on my 34.20210904.3.0 machine, and I’m also puzzled because that specific user is shipped as part of the commit (in /usr/lib/passwd).

This is possibly coming as a side-effect of some custom configuration. Is this machine a freshly installed one or was initially installed at an older version? How does the Ignition configuration look like?

3

I think I found the culprit …


[root@fcostest ~]# id -u systemd-resolve
990

[root@fcostest ~]# ipa-client-install --unattended -p ${IPA_USER} -w ${IPA_PASS} --domain ${IPA_DOMAIN} --ntp-pool ${NTP_POOL} --force --force-join
This program will set up IPA client.
Version 4.9.6

...

The ipa-client-install command was successful

[root@fcostest ~]# id -u systemd-resolve
id: ‘systemd-resolve’: no such user
4

This is likely an issue with authselect. Basically, what you will likely find is that after you run the ipa-client-install command, the passwd/group entries all got modified within /etc/nsswitch.conf to drop all “altfiles” references, which are needed to determine the UIDs/GIDs of system users/groups. Obviously this causes a lot of issues if you want a workable system.

I found this to be a problem in Kinoite earlier in the month when hooking a system into FreeIPA, so I submitted a pull request to fix it. The change was committed as seen here:

https://github.com/authselect/authselect/commit/c2b1b7a72b8b2efb3c244feca65abd692b0ed599

It seems that the check may need extended to CoreOS, if the same fix will work there. The fix already existed for Silverblue, so my patch was very minimal to just add Kinoite.

The current check just parses /etc/os-release for a case-insensitive match for “silverblue” or “kinoite”, and acts accordingly. It is possible the fix can be made more generic to just do a case insensitive search for “fedora” within /etc/os-release, and if that is found and /usr/bin/rpm-ostree also exists, then go down the same code path that is currently done for Silverblue and Kinoite.

I do not know enough about CoreOS to know if that would work, but it’s likely it’s that simple. Regardless, any fix won’t be in effect until a new authselect package is created, so there is no short-term clean solution.

In the meantime, if you want a quick fix, you can just add altfiles back to your nsswitch.conf entries, although that probably isn’t the best long-term fix.

1 Like
5

Thanks for the investigation here. We should make that rpm-ostree/ostree generic. I’ll take a look.

6

Made: authselect.spec: Add nss-altfiles for all ostree systems by travier · Pull Request #273 · authselect/authselect · GitHub

1 Like
7

Thank you. I like the solution you are going for, as it won’t keep requiring pull requests anytime something like a new desktop variant is released, for instance.

I look forward to when this is in place, so I can rest assured everything is in working order after hooking a machine into FreeIPA.