Un servicio parece estar funcionando, pero el archivo esperado permanece vacío. Antes de modificar su configuración o revisar cientos de líneas en journalctl, observe directamente el directorio donde debe escribir.
inotifywait muestra las creaciones, modificaciones y movimientos vistos por el núcleo. Podrá confirmar una escritura limitada y luego saber cuándo esta herramienta ya no es suficiente.
Identificar el camino antes de iniciar la vigilancia
Comience por la ruta absoluta. Un servicio systemd puede escribir en /var/log/nombre-servicio, en un directorio de aplicación o únicamente en el registro del sistema. En Debian y Ubuntu, verifique primero la unidad y sus registros:
sudo systemctl status mi-servicio --no-pager
sudo journalctl -u mi-servicio -n 50 --no-pagerSi ya tiene un archivo específico, verifique su propietario, sus derechos y el espacio disponible. Una vigilancia no corrige ni un directorio ausente ni un disco lleno.
sudo ls -ld /var/log/mi-servicio
sudo df -h /var/log/mi-servicioLuego, instale inotify-tools si falta el comando. El paquete lleva este nombre en Debian y Ubuntu.
sudo apt update
sudo apt install inotify-toolsEn una máquina RHEL, Fedora o Rocky, el paquete también se llama generalmente inotify-tools. Verifique su nombre en el repositorio configurado antes de la instalación.
Seguir las escrituras en un directorio limitado
Abrir una sesión dedicada y vigilar un solo directorio. Este comando permanecerá en primer plano hasta Ctrl+C.
sudo inotifywait -m -e create,modify,move,delete /var/log/mi-servicioLa opción -m mantiene la vigilancia abierta. Los eventos solicitados evitan mostrar las simples consultas de archivo. Luego, inicie la acción que debe hacer que el servicio escriba, como una solicitud de prueba o un reinicio ya previsto.
Un resultado como CREATE application.log o MODIFY application.log confirma que el núcleo ha visto la operación en esta carpeta. Aún no dice si el contenido es correcto. Lea las últimas líneas del archivo:
sudo tail -n 30 /var/log/mi-servicio/application.logLa guía seguir un log con tail está justamente destinada a releer el contenido después del evento. Si el servicio solo escribe en systemd, mantenga mejor journalctl -u mi-servicio -f.
Hacer una prueba sin alterar el servicio
Antes de observar una aplicación de producción, tome una carpeta de laboratorio. Así puede verificar la sintaxis y los derechos sin mezclar sus eventos con los de un servicio activo.
mkdir -p /tmp/inotify-test
inotifywait -m -e create,modify,move,delete /tmp/inotify-testEn una segunda sesión, cree y modifique un archivo:
printf 'primera línean' > /tmp/inotify-test/probe.log
printf 'segunda línean' >> /tmp/inotify-test/probe.logLa primera sesión debe mostrar al menos una creación y una modificación. Deténgala con Ctrl+C, luego elimine la carpeta de prueba si ya no la necesita.
Elegiría esta verificación antes de una modificación de configuración, porque responde a una pregunta simple: ¿el servicio realmente alcanza el directorio esperado? No permite concluir sobre la calidad del contenido escrito.
Las limitaciones de inotifywait en producción
inotify observa los eventos locales transmitidos por el núcleo. En un directorio muy activo, la salida se vuelve difícil de explotar y la cola de eventos puede desbordarse. Entonces hay que regresar a los registros de aplicación, métricas o a una auditoría adecuada.
No lo utilice como prueba única para una investigación de seguridad. También evite las carpetas que contienen secretos o miles de archivos temporales. Para identificar un proceso que retiene un archivo o un puerto, lsof responde a otra pregunta.
Cuando el evento y el contenido del archivo corresponden a la acción de prueba, tiene una base clara para continuar el diagnóstico. Si no aparece ningún evento, vuelva a verificar la ruta, la unidad systemd y el tipo de registro antes de cambiar el servicio.
Para el comportamiento exacto de las opciones, consulte la página de manual de inotifywait.