Observar um arquivo com inotifywait para confirmar a gravação de um serviço

Um serviço parece estar rodando, mas o arquivo esperado permanece vazio. Antes de modificar sua configuração ou vasculhar centenas de linhas no journalctl, observe diretamente o diretório onde ele deve gravar.

inotifywait exibe as criações, modificações e movimentações vistas pelo núcleo. Você poderá confirmar uma gravação limitada e, em seguida, saber quando essa ferramenta não é mais suficiente.

Identificar o caminho antes de iniciar a vigilância

Comece pelo caminho absoluto. Um serviço systemd pode gravar em /var/log/nome-serviço, em um diretório de aplicativo ou apenas no log do sistema. No Debian e Ubuntu, verifique primeiro a unidade e seus logs:

sudo systemctl status meu-serviço --no-pager
sudo journalctl -u meu-serviço -n 50 --no-pager

Se você já tem um arquivo específico, verifique seu proprietário, suas permissões e o espaço disponível. Uma vigilância não corrige nem um diretório ausente nem um disco cheio.

sudo ls -ld /var/log/meu-serviço
sudo df -h /var/log/meu-serviço

Depois, instale inotify-tools se o comando estiver ausente. O pacote tem esse nome no Debian e Ubuntu.

sudo apt update
sudo apt install inotify-tools

Em uma máquina RHEL, Fedora ou Rocky, o pacote também geralmente se chama inotify-tools. Verifique seu nome no repositório configurado antes da instalação.

Seguir as gravações em um diretório limitado

Abra uma sessão dedicada e monitore um único diretório. Este comando permanece em primeiro plano até Ctrl+C.

sudo inotifywait -m -e create,modify,move,delete /var/log/meu-serviço

A opção -m mantém a vigilância aberta. Os eventos solicitados evitam exibir as simples consultas de arquivo. Em seguida, desencadeie a ação que deve fazer o serviço gravar, por exemplo, uma solicitação de teste ou uma reinicialização já programada.

Um resultado como CREATE application.log ou MODIFY application.log confirma que o núcleo viu a operação nesta pasta. Isso ainda não diz se o conteúdo está correto. Leia então as últimas linhas do arquivo:

sudo tail -n 30 /var/log/meu-serviço/application.log

O guia seguir um log com tail é justamente para reler o conteúdo após o evento. Se o serviço grava apenas no systemd, mantenha journalctl -u meu-serviço -f.

Fazer um teste sem tocar no serviço

Antes de observar um aplicativo de produção, pegue uma pasta de laboratório. Assim, você verifica a sintaxe e as permissões sem misturar seus eventos com os de um serviço ativo.

mkdir -p /tmp/inotify-test
inotifywait -m -e create,modify,move,delete /tmp/inotify-test

Em uma segunda sessão, crie e modifique um arquivo:

printf 'primeira linhan' > /tmp/inotify-test/probe.log
printf 'segunda linhan' >> /tmp/inotify-test/probe.log

A primeira sessão deve exibir pelo menos uma criação e uma modificação. Pare-a com Ctrl+C, e então delete a pasta de teste se não precisar mais dela.

Eu escolheria essa verificação antes de uma modificação de configuração, pois ela responde a uma pergunta simples: o serviço realmente alcança o diretório esperado? Ela não permite concluir sobre a qualidade do conteúdo gravado.

As limitações do inotifywait em produção

inotify observa os eventos locais transmitidos pelo núcleo. Em um diretório muito ativo, a saída rapidamente se torna difícil de explorar e a fila de eventos pode transbordar. É necessário, então, voltar aos logs de aplicativo, métricas ou um auditoria adequada.

Não o utilize como prova única para uma investigação de segurança. Evite também pastas contendo segredos ou milhares de arquivos temporários. Para identificar um processo que está retendo um arquivo ou uma porta, lsof responde a outra pergunta.

Quando o evento e o conteúdo do arquivo correspondem à ação de teste, você tem uma base limpa para continuar o diagnóstico. Se nenhum evento aparecer, verifique novamente o caminho, a unidade systemd e o tipo de log antes de mudar o serviço.

Para o comportamento exato das opções, consulte a página de manual do inotifywait.