-
-
Notifications
You must be signed in to change notification settings - Fork 13.4k
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
hostname --fqdn
broken with nsncd
#261269
Comments
This seems to happen because the resolution flow (when nscd is running) looks like:
I wonder if we can fix this by patching out the support in systemd-resolved for looking up the nodename, which will make it fall back to the result from /etc/hosts instead; on NixOS we can (probably) always assume that /etc/hosts will actually have the correct system hostname in it. |
No, this is most likely nix-community/nsncd#9. We wanted to polish that PR in the next days, and once merged, bump our nixpkgs pin (and resurrect the upstreaming attempts). If you want, can you check if using nsncd from this PR fixes the problem for you? |
Ah, actually, I think I'm just talking out of my ass. systemd-resolved seems to be able to cope with this properly when I query it over DNS, so it probably isn't to blame. |
|
This is a pretty weird behavior. What's (likely) failing here is the IPv6 resolution of Thanks for the heads up wrt. |
The behavior I described is from the Nix build environment. I used the nixpkgs derivation for nsncd and updated the source to the PR. |
Note: we decided to rewrite the history of the fork who somehow got out of hand. Feature-wise, this version bump fixes the various host faulty behaviour. See the nix-community/nsncd#9 and nix-community/nsncd#10 PRs for more details. We're in the process of upstreaming this change to twosigma/nsncd, however, upstream has been pretty slow to review our PRs so far. Since the hostname bug surfaces quite regularly in the Nixpkgs issue tracker, we decided to use the nix-community fork as canon for Nixpkgs for now. Fixes: NixOS#132646 Fixes: NixOS#261269
Describe the bug
hostname --fqdn
only returns the hostname, even when bothnetworking.hostName
andnetworking.domain
are set.Steps To Reproduce
Steps to reproduce the behavior:
networking.hostName
andnetworking.domain
.hostname --fqdn
.Expected behavior
hostname --fqdn
should return the FQDN defined bynetworking.hostName
andnetworking.domain
.Additional context
The breakage happens when
nsncd
is used, which is now the default in NixOS after #214153. Stoppingnsncd.service
causeshostname --fqdn
to return the correct value.nixosTests.hostname.explicitDomain
reproduces the issue. It broke at fbfe290, which is whennsncd
became enabled by default. It's still broken onmaster
which is b137e2f at time of writing.Possibly related issues:
Notify maintainers
@flokli @lukegb @NickCao @rnhmjoj @NinjaTrappeur @mweinelt
Metadata
The text was updated successfully, but these errors were encountered: