Automatizar com Bash: falhas, concorrência e entrega | Administração Linux para operações

Transformar o script num contrato observável

Define entradas, identidade de execução, ambiente, resultados e estados de falha antes de escrever o wrapper. Um scheduler pode usar outro PATH, outra diretoria e outra conta em relação ao terminal. Carregar todo o perfil pessoal de um administrador cria dependências difíceis de reproduzir. Explicita o executável, a configuração necessária e o destino autorizado. Se OUTPUT_DIR tem de estar definido e não vazio, uma guarda :? trata essa condição, mas ainda falta validar o caminho. Um exit code zero não substitui pós-condições: produzir 950 dos 1000 registos esperados continua a ser uma entrega incompleta, mesmo que a ferramenta considere a execução concluída.

Guardar a falha antes de a substituir

Uma pipeline tem estados por etapa e um estado agregado. Com pipefail, o agregado é o estado não zero mais à direita na ordem da pipeline, não o erro numericamente maior. PIPESTATUS permite observar etapas, mas outro comando, incluindo uma atribuição, pode substituí-lo. Guarda a evidência imediatamente. Usa resultados explícitos nas decisões críticas: set -e e traps ERR têm exceções em contextos condicionais e não formam um sistema de transações. Se uma função usada num if falha numa etapa e depois termina com printf bem-sucedido, pode esconder o erro. Ensaiar esse caminho é tão importante como ensaiar o sucesso.

Preservar argumentos, linhas e contexto

Uma lista de caminhos não é uma string genérica. Em Bash, a expansão entre aspas de um array com @ conserva cada elemento como argumento; * entre aspas junta elementos. Para linhas com espaços significativos e barras invertidas, usa leitura que preserve esses dados e trata o fim de ficheiro conforme o contrato. Nomes com newline exigem um delimitador que não faça parte do nome, como NUL, em toda a cadeia de ferramentas. A ordem de redireções também importa: duplicar stderr antes ou depois de redirecionar stdout produz destinos diferentes. Confirma ainda se um ciclo em pipeline corre num subshell antes de depender das suas variáveis no shell exterior.

Coordenar jobs pelo mesmo objeto

Exclusão mútua precisa de um protocolo comum. Num filesystem local com flock, os participantes devem coordenar o mesmo objeto e interpretar conflito de lock como um estado próprio. Remover o nome enquanto um processo mantém o ficheiro aberto e recriá-lo pode separar os participantes por inodes diferentes. O facto de ambos escreverem “lock adquirido” no log já não comprova coordenação. Define se um segundo job espera, falha, é adiado ou é omitido com registo. Considera também descritores herdados por filhos e as garantias do filesystem utilizado; não transfiras automaticamente um exemplo local para NFS ou CIFS sem confirmar o comportamento.

Limitar tempo e proteger a publicação

Um timeout limita execução, não desfaz efeitos já emitidos. Se um pedido remoto foi enviado e a resposta não chegou, consulta a identidade da operação antes de repetir. No GNU timeout, kill-after acrescenta um intervalo após o sinal inicial; dimensiona o orçamento completo e não prometas término funcional apenas porque um sinal foi enviado. Cria temporários com uma operação que também reserve o objeto: mktemp -u só sugere um nome. Liga a publicação às pós-condições e ao contrato de persistência ensinado no módulo de filesystems. Finalmente, o trap de limpeza deve preservar o estado relevante do job e tratar a sua própria falha sem mascarar o resultado.

set +e
set -o pipefail
( exit 7 ) | ( exit 3 ) | cat
stage_status=( "${PIPESTATUS[@]}" )
printf "stage=%s\n" "${stage_status[@]}"

NA PRÁTICA

Exercício de leitura: as três etapas devolvem 7, 3, 0. Com pipefail, o agregado é 3. Se guardares PIPESTATUS imediatamente, obténs os três estados; se executares primeiro outro comando, podes perder essa evidência. Este exemplo não produz ficheiros nem envia pedidos. Executa este exemplo num Bash isolado: set +e torna explícita a continuação após a pipeline com falha; não é um wrapper de produção.

Armadilhas comuns

Confiar apenas em set -e; ler PIPESTATUS tarde; exportar uma variável esperando propagação do filho para o pai; apagar locks ativos; usar timeout como rollback; publicar só porque existe um ficheiro.

Tópicos relacionados: Separar DNS, ligação, TLS e aplicação · Shell: argumentos, pipelines e códigos de saída · Isolar recursos e comprovar prontidão em Linux · Recuperar filesystems e publicar dados com segurança

Leva esta ideia contigo

Preserva a evidência de cada etapa e publica apenas quando execução, conteúdo, concorrência e confirmação satisfazem o contrato definido.

Criar conta

Referência: bash(1) · DR Linux 2026.4; networking and Bash manuals reviewed 2026-10-01; cgroup v2 and upstream systemd manuals reviewed 2026-10-01; RHEL 10 examples; Linux man-pages 6.19; OpenSSL 3.5