쉘 프롬프트를 얻는 데 수십 초가 걸리는 이유는 무엇입니까?


30

서버에 SSH를 연결 한 후 (또는 Mac에서 터미널을 연 후에도) 로그인 배너가 즉시 인쇄되지만 셸 프롬프트가 표시되기까지 ~ 10 초에서 1 분 정도 걸립니다. 그 후에는 성능이 좋으며 네트워크 대기 시간이 드문 일이 아닙니다.

이것은 계산 상 어렵거나 메모리 집약적이거나 IO가 많은 작업처럼 보이지 않습니다. 수십억 개의 모든 CPU 사이클에서 무엇을하고 있습니까?


8
ssh -v -v -vur_shell -x신중한 디버깅 단계 수 있습니다.
thrig

2
당신의 라인이 많이 .bash_history있습니까?
kasperd

2
.profile 및 관련 파일을보고 (죄송합니다. 사용중인 쉘이 확실하지 않음) 일시적으로 제거하여 기능이 향상되는지 확인하십시오. 시간이 초과 된 명령이있을 수 있습니다.
TheFiddlerWins

3
Moby Disk의 제안과 달리 쉘 내에서 쉘 자체를 시작하면 여전히 느리게 진행됩니까? 기존의 연결된 세션 내에서 두 번째 셸을 시작할 때 (다시) 연결이 느리지 만 속도가 느리면 속도가 느려지는 셸 자체가 아니라는 것을 알 수 있습니다. 두 상황에서 속도가 느리면 시작시 쉘이 수행하는 데 많은 시간이 걸립니다. 어느 쪽이든 "0에서 셸 프롬프트까지"의 어떤 측면이 느린 지에 대해 배울 수 있습니다.
CVn

2
이것은 종종 GSSAPI 인증을 시도하는 것입니다 (Kerberos 상점이 아닌 경우 완전히 쓸모가 없을 수 있음). 다른 경우에는 DNS 역방향 조회입니다.
Charles Duffy

답변:


33

여기서 몇 가지 일이 일어날 수 있습니다. 쉘 매뉴얼에서 대부분의 답변을 찾을 수 있지만 일반적으로 매우 길고 비스듬합니다.

문제가 몇 가지 사항 중 하나로 귀결 될 가능성이 있습니다.

프로필이나 bashrc에 값 비싼 물건이 있으면 다시 잘라내는 것을 고려하십시오.

프로파일 또는 bashrc가 역방향 DNS 조회를 사용하여 (프롬프트 또는 기타 설정) DNS를 수정하거나 호스트 이름을 대신 사용하십시오.

쉘은 초기화하는 동안 무엇보다도 많은 파일을 엽니 다. 시스템로드가 높으면 여기에 종종 표시됩니다.

배너가 사전 인증 인 경우 실제로 인증 (pam, LDAP 등)이 느릴 수도 있습니다.

그러나 이것들 중 어느 것도 아닐 수도 있습니다. 프롬프트를 표시하기 직전에 놀라운 양의 일이 발생합니다!


1
상당한 시간 동안 블록을 본 또 다른 하나는 GSSAPI 인증을 시도한 것입니다 (SSH 클라이언트 또는 서버 구성에서 전원을 끄지 않은 경우). sysdig와 같은 전체 시스템 추적 도구를 사용하는 것이 아마도 이런 종류의 교차 문제의 맨 아래에 도달 할 수있는 최고의 은색 총알 일 것입니다.
Charles Duffy

+1 철저한 답변. 이 사이트 에는 로그인, 실행 / 소스 및 기타 정보에 대한 멋진 순서도가 있습니다.
Tim S.

15
+1. 99 %의 시간은 역방향 DNS 조회입니다.
mpontillo

@ Mike : 여기에서 동일-수정하기 쉬운 것으로 시작하는 것이 좋습니다. 내 경우에는 100 %였습니다.
WoJ

22

DNS를 기다리거나 LDAP 등을 통해 인증을 시도했을 수 있습니다.

UseDNS no/ etc / ssh / sshd_config 에 추가하십시오

로컬 로그온에서도 수행되는 경우 구성한 LDAP 서버 또는 DNS 서버가 느리거나 응답하지 않는지 확인하십시오.


6

하나의 가능성 (다른 답변들에 의해 커버 됨)은 SSH 세션 자체를 설정하는 프로세스가 시간을 잃어버린 곳이라는 것입니다.

또 다른 대안은 SSH 세션 설정 후 원격 시스템에서 실행되는 쉘 시작 스크립트에 시간이 오래 걸리는 것입니다 (아마 깨진 네트워크 마운트에 액세스하려고 시도 함). 다음과 같이이 두 번째 가능성을 디버깅 할 수 있습니다.

일시적으로 상단에 다음을 추가하십시오 ~/.bash_profile.

set -x
PS4='+ $(date "+%s.%N")\011 '

set -x모든 쉘 명령에 대한 몇 가지 디버깅에 회전이 실행. PS4디버깅이 표시되는 방법을 변수 컨트롤 - 특히이 경우 우리가 사용하는 date타임 스탬프를 추가 할 수 있습니다.

그런 다음 디버깅 출력의 타임 스탬프를 분석하여 시작 스크립트에서 어떤 명령이 너무 오래 걸리는지 확인할 수 있습니다.


1
원격 세션을 연 후 문제가 발생하는 경우에만 해당됩니다. 잠재적 인 원인 중 다수는 SSH 핸드 셰이크 및 인증 중에 발생합니다.
Charles Duffy

2
많이 향상되었습니다. :)
Charles Duffy

3

Ubuntu 서버 인 경우 기본 로그인 설정은 로그인 쉘이 실행될 때마다 패키지를 업데이트 할 수 있는지 확인합니다. 패키지 목록이 디스크 캐시에 없으면 빠른 유휴 데스크톱에서도 1-2 초가 걸릴 수 있습니다.

$ ssh localhost 
Welcome to Ubuntu 15.04 (GNU/Linux 3.19.0-26-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

*** System restart required ***
Last login: Sat Sep 12 01:38:38 2015 from localhost

"다시 시작해야 함"메시지를 생성하려면 현재 실행중인 커널이 현재 설치된 기본 커널이 아닌지 확인해야합니다. (즉, 커널이 있었고 아직 재부팅하지 않았습니다.) 또한 사용 가능한 보안 업데이트가있는 경우 인쇄합니다.

최근 도입 된 우분투에 로그인 할 때 속도가 느려지는 것 같습니다.

그렇지 않으면 ~/.bash_profile/ ~/.bashrc문제 일 수 있습니다.

서버 자체에서 서버에 로그인을 시도 했습니까 ( ssh localhost)? 아니면 두 번째로 바로 로그인합니까? (물건이 캐시 될 때 훨씬 더 빠른지 확인하십시오.)


2

이다 대부분의 경우 DNS 요청의 타임 아웃.

원인 : 서버가 클라이언트의 IP 주소를 사용하여 역방향 DNS 조회를 시도했지만 응답을 얻지 못했습니다. A가 B에 연결되면 B는 A의 IP 주소를 이름으로 변환하려고 시도합니다.

해결 방법 : 서버의 호스트 파일에 클라이언트의 IP 주소와 이름을 입력하십시오.

해결 방법 : 모든 호스트를 DNS 서버에 알리십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.