我有一个关于域名解析的非常烦人且令人困惑的问题,仅关注apt
/apt-get
实用程序。
当我尝试时apt update
,它给了我(对不起,法语)
root@myhostname:~# apt update
Err :1 http://ftp.igh.cnrs.fr/pub/os/linux/raspbian/raspbian buster InRelease
Erreur temporaire de résolution de « ftp.igh.cnrs.fr »
测试与分析
实际上,所有其他测试资源的 DNS 解析都可以
- ✔
nslookup ftp.igh.cnrs.fr
给我Non-authoritative answer: ftp.igh.cnrs.fr canonical name = ftp4.igh.cnrs.fr. Name: ftp4.igh.cnrs.fr Address: 193.50.6.155
- ✔ 我也可以尝试,
nslookup ftp.igh.cnrs.fr 8.8.8.8
得到同样的结果
注意:在这两个第一次测试中,我的响应出现了奇怪的长时间延迟
- ✔
dig ftp.igh.cnrs.fr
给我相同的结果
- ✔
✔ 我可以使用相同的 URL 成功运行
wget
或命令curl
root@myhostname:~# curl http://ftp.igh.cnrs.fr/pub/os/linux/raspbian/raspbian <html> <head><title>301 Moved Permanently</title></head> <body bgcolor="white"> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html>
wget http://ftp.igh.cnrs.fr/pub/os/linux/raspbian/raspbian --2021-06-17 12:56:26-- http://ftp.igh.cnrs.fr/pub/os/linux/raspbian/raspbian Résolution de ftp.igh.cnrs.fr (ftp.igh.cnrs.fr)… 193.50.6.155 Connexion à ftp.igh.cnrs.fr (ftp.igh.cnrs.fr)|193.50.6.155|:80… connecté. requête HTTP transmise, en attente de la réponse… 301 Moved Permanently Emplacement : http://ftp.igh.cnrs.fr/pub/os/linux/raspbian/raspbian/ [suivant] --2021-06-17 12:56:26-- http://ftp.igh.cnrs.fr/pub/os/linux/raspbian/raspbian/ Réutilisation de la connexion existante à ftp.igh.cnrs.fr:80. requête HTTP transmise, en attente de la réponse… 200 OK Taille : non indiqué [text/html] Sauvegarde en : « raspbian »
✔ 如果我尝试任何网络命令例如
ssh
,它再次起作用下一步,我考虑了 APT 存储库的可用性本身(如果错误消息可能不可靠 - 你永远不知道;-))
- 尝试使用其他 APT 存储库
/etc/apt/sources.list
给出完全相同的不良结果。
- 尝试使用其他 APT 存储库
关于全局系统性能,我想知道系统缓慢和 DNS 解析失败之间是否存在任何关系。
我还杀死了所有繁重的进程。 (例如打开的网络浏览器)。
这里是top
剩余结果的示例1 root 20 0 34824 8304 6496 S 1,3 0,9 0:26.26 systemd 8596 root 20 0 10292 2876 2380 S 1,0 0,3 0:06.02 top 120 root 20 0 32600 11760 10732 S 0,7 1,3 0:08.62 systemd-journal 742 root 20 0 8144 3016 2836 S 0,7 0,3 0:00.55 check-vpn 10878 root 20 0 10192 2792 2436 R 0,7 0,3 0:00.14 top 12 root 20 0 0 0 0 I 0,3 0,0 0:02.68 rcu_sched 13 root rt 0 0 0 0 S 0,3 0,0 0:00.02 migration/0 110 root 0 -20 0 0 0 I 0,3 0,0 0:00.19 kworker/3:2H-kblockd 299 root 20 0 0 0 0 S 0,3 0,0 0:02.30 brcmf_wdog/mmc1 380 message+ 20 0 6664 3588 3084 S 0,3 0,4 0:10.36 dbus-daemon 739 vnstat 20 0 2440 432 372 S 0,3 0,0 0:00.43 vnstatd 761 root 20 0 0 0 0 I 0,3 0,0 0:03.51 kworker/u8:3-brcmf_wq/mmc1:0001:1 10624 root 20 0 0 0 0 I 0,3 0,0 0:00.29 kworker/0:1-events 10757 root 20 0 0 0 0 I 0,3 0,0 0:00.03 kworker/2:0-events 2 root 20 0 0 0 0 S 0,0 0,0 0:00.01 kthreadd 3 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_par_gp
我注意到这个列表中有一个循环
kworker
过程。正常吗?
但从全球来看,系统的负载似乎不太高Tasks: 141 total, 1 running, 139 sleeping, 1 stopped, 0 zombie %Cpu(s): 0,7 us, 1,0 sy, 0,0 ni, 98,1 id, 0,0 wa, 0,0 hi, 0,2 si, 0,0 st MiB Mem : 872,7 total, 275,2 free, 123,7 used, 473,8 buff/cache MiB Swap: 100,0 total, 100,0 free, 0,0 used. 679,3 avail Mem
在全球范围内,我没有发现任何其他命令行或图形工具导致 DNS 解析失败。 !❓
全球行动
- 我尝试重新启动一些服务但没有任何结果
systemctl restart resolved
systemctl restart systemd-resolved
- ⛔ 即使我重新启动网络,它也会失败
systemctl restart networking
- ⛔ 即使我重新启动系统,它也会失败
- 我尝试重新启动一些服务但没有任何结果
DNS 配置文件
我检查了以下文件:
/etc/resolv.conf
nameserver 8.8.8.8 option timeout:7
/etc/resolvconf/run/resolv.conf
nameserver 192.168.95.1 nameserver 127.0.0.53 search lan
/var/run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 192.168.95.1 nameserver 127.0.0.53 search lan
/etc/network/interfaces
auto eth0 allow-hotplug eth0 iface eth0 inet dhcp auto wlan0 allow-hotplug wlan0 iface wlan0 inet dhcp wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
我还检查了只有一个接口 eth0,具有静态 IP。相同的结果。
操作系统配置详细信息
- 我正在运行 Debian 10.9。 (与树莓派发行版)
- 问题似乎在我的一半设备上随机触发(我有大约 100 台设备)
解决方法。
我发现解决此问题的唯一方法是重新安装 resolvconf 服务
apt purge -y openresolv resolvconf
wget http://ftp.igh.cnrs.fr/pub/os/linux/raspbian/raspbian/pool/main/r/resolvconf/resolvconf_1.79_all.deb
dpkg -i resolvconf_1.79_all.deb
systemctl restart systemd-resolved.service
systemctl enable systemd-resolved.service
但它并不可靠:我必须在每次重新启动后执行此操作。坏方法...
知道我的系统出了什么问题吗?
答案1
在挖掘这种奇怪的情况时,我从讲述权限的文章中得到了灵感。初读时,与我的问题无关。
无论如何,我已经检查了文件权限,/etc/resolv.conf
一切看起来都正常,除了一个特定的点:是一个指向路径/etc/resolv.conf
的符号链接/opt/...
即使权限看起来正确,我也尝试仅复制文件而不是链接它。然后哈利路亚,它成功了..
不要问我为什么apt
检查此设置与全局操作系统不同,我不知道为什么。但这就是解决方案!