← LFCS: administração Linux em produção
09 / 9 · 60 MIN

Contexto de execução, dependências e resultados

Liga dependências systemd, configuração SSH e estados Bash à operação de negócio realmente concluída.

Ler dependências como contratos explícitos

After define ordem entre unidades envolvidas numa transação; não ativa por si a outra unidade. Um serviço que precisa de /srv/ledger/data deve declarar as dependências adequadas dos mounts, além da ordem. RequiresMountsFor pode acrescentar Requires e After para os mounts necessários ao caminho, com configuração e suporte verificados. Isto não substitui validar o volume efetivo nem os dados. O exemplo usa documentação systemd v258; consulta a versão instalada antes de copiar opções. Um nome de unidade aparentemente relacionado com data não prova que representa o mount exigido.

Tratar escritas no destino errado

Se o serviço arrancar antes do volume, pode gravar no diretório subjacente do filesystem raiz. Montar o volume por cima pode ocultar essas escritas sem as eliminar ou reconciliar. Interrompe trabalho de acordo com o plano aprovado, identifica o destino real e preserva os dados necessários à recuperação. Corrige a dependência e verifica o comportamento após um arranque controlado. Uma espera fixa não demonstra que o volume certo está disponível. Inclui no handover o que observar quando a montagem falha, para que RUN não aceite silenciosamente um destino alternativo.

Distinguir arranque, readiness e retries

Um Type=simple pode estar ativo enquanto a aplicação ainda carrega dados. Uma unidade dependente precisa de readiness compatível ou de espera e retry apropriados; mudar para Type=notify sem suporte não produz READY=1. Do mesmo modo, Restart=on-failure não garante recuperação de configuração inválida. Quando há start-limit-hit, corrige a causa, confirma o estado efetivo e repõe o contador conforme necessário antes de ensaiar. Remover limites permanentemente pode apenas prolongar uma falha repetida. O critério final deve incluir uma operação útil da aplicação, não só o estado do processo.

Identificar quem interpreta e abre o destino

ExecStart não interpreta automaticamente > como uma redireção da shell. Escolhe configuração de output ou um wrapper com interpretação explícita e âmbito controlado. Numa shell interativa, sudo aplicado ao comando também não eleva automaticamente a abertura feita pela shell para >. O processo que abre o destino precisa da autorização adequada. Não corrijas isso tornando um ficheiro protegido mundialmente gravável. Distingue a sintaxe lida pelo gestor, os argumentos recebidos pelo programa e os ficheiros abertos antes da execução. Essa sequência explica diferenças entre um comando manual e o serviço.

Guardar estados antes de os substituir

Em Bash sem pipefail, false | true devolve zero porque o último comando teve sucesso. Com pipefail, a falha anterior produz estado não zero. PIPESTATUS permite observar componentes, mas outro comando pode substituir a array; guarda-a imediatamente. O exemplo abaixo não toca em ficheiros nem serviços e pode ser ensaiado numa shell isolada. As verificações locais desta expansão usam Bash 3.2 no macOS para estes comportamentos de shell, não um laboratório Linux. A transferência para um job real ainda exige analisar traps, errexit, subprocessos e a forma como o scheduler recebe o resultado.

Confirmar configuração SSH e família de endereços

Para opções como User, OpenSSH usa normalmente o primeiro valor obtido. Host * com User general antes de Host ledger com User batch pode fixar general no caso simples sem overrides. ssh -G ajuda a inspecionar a configuração avaliada, mas não testa ligação nem autenticação. Também não confundas escuta IPv6 com cobertura IPv4: um socket [::] com IPV6_V6ONLY=1 explicitamente definido não aceita IPv4. Identifica contexto, opções e família antes de alterar firewalls. Os exercícios não assumem defaults iguais em todos os sistemas ou versões.

Aceitar resultados de negócio completos

Um compressor pode produzir um ficheiro válido com apenas metade dos registos esperados. Propagar falhas de etapas é necessário, mas estados zero também não provam completude. Define contagem, integridade, reconciliação e condições de publicação apropriadas ao job. Se a validação falhar, preserva o resultado parcial como evidência conforme o processo e impede que seja tratado como entrega concluída. Na comunicação internacional, separa processo concluído, ficheiro criado e exportação reconciliada. Estes termos descrevem estados diferentes e evitam que uma equipa consuma dados incompletos por interpretar sucesso de forma demasiado ampla.

set -o pipefail
false | true
steps=("${PIPESTATUS[@]}")
printf 'first=%s last=%s\n' "${steps[0]}" "${steps[1]}"
NA PRÁTICA

false | true devolve 0 por defeito; com pipefail devolve 1. Nenhum dos resultados verifica a contagem de um ficheiro de negócio.

Armadilhas comuns

After como ativação, active como readiness, ExecStart como shell, ssh -G como autenticação ou zero como completude.

Tópicos relacionados: Serviços e batch · SSH e diagnóstico de rede

Leva esta ideia contigo

Um serviço recuperado precisa do contexto correto e de um resultado útil verificado, além de um processo ativo.

Criar conta

Referência: systemd.unit source manual · LFCS current five-domain outline; exact edition date unconfirmed

LFCS é uma marca comercial de The Linux Foundation. Linux® é uma marca registada de Linus Torvalds. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por The Linux Foundation ou Linus Torvalds. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.