Como sei quando um comando executado sobre o ssh terminou?

1

Estou fazendo scripts de implantação para o meu projeto e estou criando uma função que deve ser capaz de executar um comando local e remotamente (em um servidor por meio do ssh) e retornar a saída de texto.

Ao executar um comando local, posso facilmente saber se o comando terminou aguardando seu PID. Quando eu envio um comando através de uma conexão SSH aberta, recebo a saída de volta, mas não sei se o comando saiu ou se o comando ainda está em execução e gerará mais saída depois.

Atualmente eu "resolvi" isso abrindo uma nova conexão com o servidor para cada comando, o que é desnecessário dizer que é dolorosamente lento .

Isso parece ser um problema comum e pode ter uma solução simples, talvez até mesmo algo embutido no SSH, por isso estou perguntando aqui: Como eu posso, através de uma conexão SSH aberta, saber se os comandos Eu mandei estão acabados. Se eu pudesse de alguma forma coletar o código de saída também seria ótimo.

Para dar um exemplo mais concreto, isso basicamente demonstra meu problema em Ruby:

io = IO.popen(["ssh", "-q", "my-server"], "r+")

io.write("some command\n")

# Sleep for some arbitrary amount of time, because I don't know when the
# command has finished :(
sleep 1

output = io.readpartial(1_000_000)

io.write("some command\n")

# Sleep for some arbitrary amount of time, because I don't know when the
# command has finished :(
sleep 1

output = io.readpartial(1_000_000)
    
por Hubro 23.06.2015 / 18:09

2 respostas

2

Envolva seu comando em um script que avisará quando terminar.

Se você tem um servidor SMTP disponível que aceita e-mails de saída do seu servidor, você pode usar isso.

O exemplo abaixo executará your-command , capturará sua saída e stderr em um arquivo e, em seguida, usará malix para enviar os resultados. Há certamente uma maneira muito melhor de garantir que o arquivo que a saída é capturada seja exclusivo do que usar a $$ pseudovariable (talvez use uma rotina que gere uma string aleatória).

#/bin/bash
your-command > /tmp/$$.$0.output 2>&1
RESULT=$?
echo >> /tmp/$$.$0.output
echo "Exit code $RESULT" >> /tmp/$$.$0.output
cat /tmp/$$.$0.output | mailx -s "your-command has finished with exit code $RESULT." [email protected]
rm /tmp/$$.$0.output

Se você quiser algo que permita especificar uma fila de comandos, procure em Task Spooler ( apt-get install tsp no Debian) que permite adicionar e eliminar comandos de uma fila e acredito pode até enviar por e-mail a saída deles.

Lendo sua pergunta com mais cuidado ... parece que você está tratando o que a conexão SSH está inserindo / enviando como um fluxo de I / O bruto.

O SSH fornece um pipe criptografado e possui alguns recursos para o encaminhamento de portas, e não muito mais. A coisa típica conectada a esse pipe é um shell que geralmente espera um usuário interativo do outro lado.

Eu acho que chaves de propósito único podem alcançar o que você está tentando fazer com facilidade, mas O mais fácil é criar um pequeno script de wrapper que faça isso:

#/bin/bash
$@ 
echo "==== Command Output Finished ===="

e, em seguida, procure a string ==== Command Output Finished ==== em suas rotinas de I / O para determinar onde está o limite entre as saídas de comando. Claro que você tem que escolher algo que não poderia ser parte de uma saída válida para um comando. Um esquema mais elaborado é possível.

O SMTP faz algo semelhante com seus cabeçalhos de limite.

    
por 23.06.2015 / 18:28
0

Se você mantiver a solução de cada comando executado em uma sessão SSH separada, poderá acelerar o tempo necessário para iniciar cada sessão usando uma conexão já aberta. Isso significa que você só precisa pagar a sobrecarga de conexão uma vez, tornando as sessões subsequentes rápidas para começar.

A maneira mais simples de configurá-lo é abrir a primeira conexão com isso:

ssh -M -S /tmp/ssh_mux_%h_%p_%r myserver

Em seguida, abra cada conexão subsequente com:

ssh -S /tmp/ssh_mux_%h_%p_%r myserver "command"

Há mais informações na% man_de% manpage em ssh_config e ControlMaster ou on-line aqui e aqui .

    
por 23.06.2015 / 21:53

Tags