Un servicio parece estar funcionando, pero el archivo esperado sigue vacío. Antes de modificar su configuración o buscar entre cientos de líneas en journalctl, observe directamente el directorio donde debe escribir.
inotifywait muestra las creaciones, modificaciones y movimientos que ve el núcleo. Podrá confirmar una escritura limitada, y luego saber cuándo esta herramienta ya no es suficiente.
Identificar la ruta 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 solo en el registro del sistema. En Debian y Ubuntu, primero verifique 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, controle su propietario, sus permisos 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-servicioA continuación, 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 generalmente se llama 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 archivos. Luego, desencadene la acción que debe hacer que el servicio escriba, por ejemplo, una consulta 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 este directorio. Aún no dice si el contenido es correcto. Lea entonces las últimas líneas del archivo:
sudo tail -n 30 /var/log/mi-servicio/application.logLa guía seguir un log con tail sirve precisamente para releer el contenido después del evento. Si el servicio solo escribe en systemd, mantenga mejor journalctl -u mi-servicio -f.
Realizar una prueba sin tocar el servicio
Antes de observar una aplicación de producción, tome una carpeta de laboratorio. De esta manera, verifica la sintaxis y los permisos 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 luego 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, ya que 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 es necesario regresar a los registros de aplicaciones, a las métricas o a una auditoría adecuada.
No lo use como única prueba para una investigación de seguridad. También evite los directorios que contengan 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 coinciden con la acción de prueba, tiene una base limpia 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.