a sessão ssh não interativa não termina, o processo sshd espera para sempre depois que um script sai

6

Executamos um script de implantação simples remotamente usando um comando como ssh [email protected] sudo /root/run-chef-client.sh . Ele começou a travar hoje porque sshd esperou para sempre no 10.170.4.11 mesmo depois de sudo ter terminado. Nós iniciamos sshd no modo de depuração e obtivemos dois tipos diferentes de logs. O seguinte é um log normal quando a sessão não é interrompida:

debug1: Received SIGCHLD.
debug1: session_by_pid: pid 23187
debug1: session_exit_message: session 0 channel 0 pid 23187
debug1: session_exit_message: release channel 0
Received disconnect from 10.170.4.6: 11: disconnected by user

E quando trava, obtemos o seguinte:

debug1: Received SIGCHLD.
debug1: session_by_pid: pid 24209
debug1: session_exit_message: session 0 channel 0 pid 24209
debug1: session_exit_message: release channel 0

Nosso entendimento é que o processo do servidor aguarda alguma comunicação de um lado do cliente e nunca a obtém. É difícil dizer se é um problema do lado do cliente ou do lado do servidor. Tentamos executar sshd em strace , mas não obtivemos êxito porque um bit SUID em sudo foi ignorado neste caso. Então, o que mais devemos tentar depurar / evitar essas situações?

    
por Alex 02.04.2013 / 17:41

1 resposta

4

Usando ssh -t (alocação de PTY forçada) em um lado do cliente, resolveu o problema:

debug1: Received SIGCHLD.
debug1: session_by_pid: pid 31701
debug1: session_exit_message: session 0 channel 0 pid 31701
debug1: session_exit_message: release channel 0
debug1: session_pty_cleanup: session 0 release /dev/pts/1
Received disconnect from 127.0.0.1: 11: disconnected by user
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials

sshd é controlado por um pseudo TTY e não por um cliente mais.

    
por 02.04.2013 / 18:46

Tags