Executar comandos administrativos do Linux de forma não interativa em agentes autônomos

O que é

A maioria das ferramentas de linha de comando do Linux foi projetada para um terminal interativo: pagina saídas longas, pede confirmação antes de ações destrutivas e formata números e datas conforme o locale da sessão. Numa sessão autônoma de um agente não há ninguém para folhear a saída, responder a um prompt ou perceber um travamento, e por isso cada um desses comportamentos padrão precisa ser sobrescrito explicitamente.

Por que importa

Um comando que fica bloqueado à espera de um paginador ou de uma resposta a "are you sure? [y/N]" não falha: ele trava até que algo mais acima na pilha estoure o tempo limite, o que é mais difícil de diagnosticar do que um erro imediato. Já um comando que termina com sucesso, mas formata números ou datas segundo o locale errado, gera uma saída que o parser lê de forma incorreta sem que ninguém perceba.

Como aplicar

• Desative os paginadores explicitamente, em vez de confiar nos padrões: passe --no-pager às ferramentas que o suportam (journalctl --no-pager, systemctl --no-pager) e exporte SYSTEMD_PAGER=cat e PAGER=cat como alternativa geral para tudo o que consulta essas variáveis.
• Evite os prompts interativos dos gerenciadores de pacotes: no Debian/Ubuntu, use DEBIAN_FRONTEND=noninteractive apt-get install -y <pkg>; em sistemas da família RHEL/Fedora, dnf install -y <pkg> (ou yum install -y). Passe sempre um -y/--assumeyes explícito, em vez de depender de um frontend não interativo para assumir a confirmação em silêncio.
• Nunca conte com um prompt interativo de senha do sudo numa sessão autônoma: sudo -n <command> falha imediatamente com status de saída diferente de zero se uma senha for necessária, em vez de travar num prompt sem terminal para respondê-lo. É exatamente esse o modo de falha que se deve detectar cedo e de forma explícita.
• Limite com timeout <seconds> <command> todo comando que possa travar por causa de rede ou de disputa por locks. Verifique $? depois, pois timeout sai com o código 124 especificamente quando precisou matar o comando, o que distingue um timeout de uma falha do próprio comando (com --preserve-status, o timeout sai com o status do próprio comando mesmo após o tempo esgotado, o que esconde essa distinção).
• Defina um locale analisável antes de extrair dados da saída de comandos: LC_ALL=C <command> (ou LC_ALL=C.UTF-8) força formatação estável e sem localização de números, pontos decimais e datas. Essa variável é lida do ambiente do processo, como uma das variáveis padrão consultadas por todo programa baseado na biblioteca C.
• Defina TERM=dumb (ou deixe-a indefinida) quando não houver terminal real conectado, para que as ferramentas que consultam TERM em busca de recursos de cor e de cursor não emitam sequências de escape ANSI na saída capturada. Capture e verifique explicitamente o código de saída de cada comando, em vez de confiar apenas no texto da saída para saber se houve sucesso.

Armadilhas

• Adicionar -y a um gerenciador de pacotes sem definir também a variável do frontend não interativo, o que ainda deixa alguns prompts de conffile ou debconf capazes de bloquear em sistemas da família Debian.
• Tratar todo código de saída diferente de zero de sudo -n como falha do próprio comando. sudo -n sai com 1 e imprime sudo: a password is required quando a regra exige senha; por isso, verifique essa mensagem no stderr antes de tentar de novo ou de escalar para uma pessoa.
• Esquecer que --no-pager e PAGER=cat cobrem caminhos de falha diferentes: uma ferramenta que chama less diretamente, ignorando $PAGER, ainda precisa da sua própria flag de desativação do paginador.