Evite mensagens "Conexão compartilhada com <host> fechado"


11

Estou gerenciando muitos sites drupal e tentando automatizar algumas coisas usando o drush. O drush run chama localmente o drush no host remoto via ssh usando as opções especificadas na configuração para o alias do site. Estou fazendo muitas dessas chamadas, para acelerar, uso conexões ssh persistentes com a configuração ssh da seguinte maneira:

Host *
  # see http://www.revsys.com/writings/quicktips/ssh-faster-connections.html
  ControlMaster auto
  ControlPath ~/tmp/%r@%h:%p
  ControlPersist 3600

Recebo uma aceleração, mas também recebo mensagens assim:

$ drush @alias drupal-directory webform 

/var/local/www/example.com/htdocs/sites/all/modules/contrib/webform
Shared connection to 12.34.56.78 closed.

A mensagem sobre a conexão compartilhada está no stdout, junto com a saída que eu quero (sério? Por que não o stderr?); Portanto, está causando problemas quando tento capturar a saída nos meus scripts:

directory=$(drush @$alias drupal-directory $module)

Espero que a conexão principal seja aquela que eu já tinha aberto, e não parece que ela esteja fechada. Então talvez o drush esteja explicitamente fazendo dessa nova conexão uma conexão mestre e fechando-a? De qualquer forma, existe uma maneira de suprimir a mensagem sobre o fechamento da conexão?

[Esta questão está em um contexto drupal / drush, mas acho que é fundamentalmente sobre ssh. Este é o site certo, então?]

EDITAR:

Parece que o problema é específico de onde a -topção para ssh está em uso. Estou usando isso porque as senhas svn precisam ser inseridas em vários pontos e -t, sem elas , as solicitações de senha não são exibidas. Talvez haja outra maneira de impedir que essas solicitações sejam perdidas?


1
1) Sim, certamente parece que você está no lugar certo. 2) bastaria um hack feio directory=$(drush @$alias drupal-directory $module | grep -v "Shared connection to")?
terdon

É aproximadamente o que estou fazendo no momento. Só que é mais desagradável do que isso com feeds de linha e outras coisas para lidar, e é em muitos lugares, então eu realmente espero que haja alguma maneira de obter ssh para ficar quieto sobre isso.
Mc0e 19/03/2015

A "Conexão compartilhada com 12.34.56.78 foi fechada". a saída da mensagem está realmente no stderr, não no stdout.
Dereckson

@ Dereckson - não, a menos que alguém o conserte.
mc0e 4/02

Respostas:


9

Condições da mensagem

De acordo com esta parte do código-fonte portátil OpenSSH , são necessárias duas condições para imprimir esta mensagem:

  • alocação pseudo-tty está ativada (-t), como você já notou
  • o nível do log deve ser diferente de QUIET

Solução para suprimir a mensagem

  • Adicione -o LogLevel=QUIETà sua sshlinha de comando.
  • Edite ~ / .ssh / config e adicione LogLevel QUIETnos Hostblocos relevantes .

Por exemplo, eu uso essa linha em um script sh conectado a vários servidores para executar comandos do Docker, alguns potencialmente interativos:

SSH = "ssh -t -o LogLevel=QUIET"

Aviso: qualquer erro é descartado

Uma desvantagem deste método é que isso também suprime erros fatais do SSH.

$ ssh -t -o LogLevel=QUIET notexisting.notld ssh anotherone.notld
$

Alternativa: registrar a saída stderr em vez de imprimi-la

Se o stderr ainda é considerado importante para obter, uma alternativa é redirecionar o stderr para o syslog, com ssh -t -y(mas você inundaria seu log com todas essas Shared connection to <host> closedmensagens).


2
Segundo essa fonte, a mensagem vai para stderr - talvez seja uma mudança em relação à versão em uso pelo questionador? Se sim, talvez valha a pena considerar uma atualização.
Toby Speight

Eu realmente não quero as mensagens "Conexão compartilhada com <host> fechado", mas geralmente quero ver as mensagens de erro no stderr. O problema não é com o ssh, é com o drush ao operar remotamente. O stderr do comando drush remoto está sendo finalizado no stdout do comando drush local.
mc0e 5/02

-o LogLevel=QUIETé uma prática padrão em ferramentas remotas de automação.
Dereckson
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.