O mais provável é que, quando executado sob cron
, a conexão foi fechada antes que o servidor remoto tivesse a chance de emitir seu banner. Isso ocorre porque openssl s_client
opera uma conexão bidirecional entre seu stdio e o soquete para o servidor remoto:
- Copia stdin para o soquete
- Copia dados recebidos no soquete para stdout
Quando executado em cron
, a primeira cópia é finalizada imediatamente, porque stdin está conectado a /dev/null
. Isso fez com que openssl
fosse encerrado imediatamente.
Você poderia mitigar isso redirecionando a entrada de openssl
para algo que bloqueia para sempre, ou melhor ainda, algo como sleep 1
, o que eliminará a necessidade de timeout
.
Ainda assim, esperar um segundo é uma forma particularmente frágil de se conectar e esperar por um banner. Não só é um tempo limite curto, mas também não faz com que o comando saia antes da expiração do tempo limite quando o banner é recebido. Para algo assim, você está procurando expect
.
A propósito:
Outros provavelmente discordarão, mas acredito que seu uso do termo "console" nesta questão seja inexato. Na verdade, você obteria o comportamento descrito pela primeira vez em qualquer sessão de terminal, o que poderia ser, entre outras coisas:
- uma sessão de terminal ssh,
- um emulador de terminal (como
xterm
ou as substituições modernas) na sua GUI - janela
screen
, - uma conexão de modem serial,
- ou o console do sistema real.
Eu acredito que o termo "console" deve referir-se exclusivamente ao último, mas todas essas são sessões de terminal.