APT - 이름 확인 오류로 인한 일시적인 실패

APT - 이름 확인 오류로 인한 일시적인 실패

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똑같은 나쁜 결과가 나왔습니다.
  • 글로벌 시스템 성능과 관련하여 시스템 속도 저하와 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
    

    또한 고정 IP를 사용하는 인터페이스는 eth0 하나만 있는 것도 확인했습니다. 같은 결과.

운영 체제 구성 세부정보

  • 저는 데비안 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/...

권한이 올바른 것처럼 보이지만 파일을 연결하는 대신 파일을 복사해 보았습니다. 그리고 할렐루야, 성공했어요..

왜 이 설정을 확인하는 것이 글로벌 OS와 다른지 묻지 마세요 apt. 이유를 모르겠습니다. 하지만 여기에 해결책이 있습니다!

관련 정보