-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
resolvconf.conf: Remove forced NSCD service restart #42569
Conversation
Forcibly restarting NSCD is unnecessary and breaks setups that use SSSD for authentication. NSCD is capable of detecting changes to /etc/resolv.conf and invalidating its caches internally. Restarting NSCD/SSSD breaks user name and UID resolution.
cc @timor |
I've had to revert this locally. I began noticing after a I finally had time to |
How does vpnc modify the DNS configuration? Is it aware of resolvconf.conf, does employ systemd-resolvd's services?
nscd's internal reload triggers at the file modification of `/etc/resolv.conf`. Maybe vpnc uses some other means that does not trigger this modification. Maybe there is a bug in nscd and it does not see the modification of the target if `/etc/resolv.conf` is a symbolic link.
I believe, nscd can be configured to watch for other files as well, but treat this as hearsay.
So, multiple routes from here to go.
|
|
@jerith666 Thank you for the data. One other thing you should also see. The journal of
If this does not happen, this would explain why nscd does not resolve hosts correctly after switching to vpn. This would look like:
As a mitigation, could you please do one more thing. Instead of restarting nscd, could you run |
I do see the I'll try with 5214655 for a few days and see if the flakiness returns. With that change,
|
Flakiness still present. Very odd, here's some more detail: I have a user-level systemd timer that essentially does:
The fetch is pulling from multiple repos all on the same host behind that vpn. The flakiness manifests in the form of some of those repos failing. But it's all in the same Anyway, this flakiness was reliably absent when I was running with the full nscd restart in Here is some journalctl output from the run on the 26th (successful, with full nscd restart) and the 27th (failed, with nscd invalidate):
|
Okay, looking around the Internet shows that nscd caching is a constant source of trouble, not just but also DNS. I'm sorry to trouble you further, but could you try to disable the nscd dns cache in |
Okay, trying with c880547, will report back results. |
While making that commit, I also noticed that https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/system/nscd.nix#L61 seems to be trying to cause
|
Sorry for the long radio silence here. I tried with c880547 for a week or two. I didn't see any lookup failures in the nightly vpn + git fetch job. However, I did see occasional failures in another job that runs every 15 mins. However, after reverting back to the original state (with |
Motivation for this change
Forcibly restarting NSCD is unnecessary and breaks setups that use SSSD for
authentication. NSCD is capable of detecting changes to /etc/resolv.conf and
invalidating its caches internally. Restarting NSCD/SSSD breaks user name and
UID resolution.
Modifying
/etc/resolv.conf
is correctly notified by the running nscd service which is watching that file.Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)