APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma unidade systemd, o processo que ela iniciou e a configuração da aplicação são objetos relacionados, mas diferentes. Se alterares um drop-in com um editor externo, daemon-reload permite ao manager reler as unidades. Não substitui automaticamente o ambiente de um processo existente. Um restart controlado pode ser necessário para iniciar um processo com os novos valores. Já systemctl edit normalmente faz a recarga do manager ao terminar; não ensines uma sequência como se qualquer edição tivesse o mesmo comportamento. reload pede uma recarga específica ao serviço quando suportada. Enable configura ativação segundo dependências, enquanto start pede execução agora. Um serviço enabled pode continuar inactive.
Aplicação guiada
Numa passagem a APS, regista identidade, diretório de trabalho, ambiente, dependências e critérios de sucesso. Um batch que lê conf/job.yml pode funcionar na shell em /opt/funds e falhar numa unidade sem WorkingDirectory. Não resolvas o caminho executando tudo como root. Nos timers de calendário, Persistent=true pode recuperar uma ativação perdida, mas não garante um replay separado de cada lote em falta. A aplicação precisa de identificar o que já processou. Nos parâmetros do kernel, uma mudança runtime por sysctl não substitui configuração persistente e verificação de precedência. Se um processo termina com 137, correlaciona eventos OOM e sinais; esse número sozinho não identifica a causa.
Antes de repetir um batch falhado, confirma se produziu ficheiros ou movimentos parciais e usa o mecanismo de reconciliação previsto.
Armadilhas comuns
daemon-reload como restart; enabled como running; ambiente da shell como ambiente do serviço; timer como fila de todos os lotes perdidos.
Tópicos relacionados: Pacotes, VMs, contentores e SELinux · Rede local, resolução e acesso SSH
Valida separadamente definição, execução atual, persistência e resultado do trabalho.
Referência: systemd.exec(5) · LFCS current five-domain outline; exact edition date unconfirmed