`tail -f` arrête parfois la mise à jour - et le fichier n'a pas bougé


10

J'ai remarqué récemment que la tail -f <logfile>mise à jour de l'écran s'arrête parfois .

Faire un Ctrl>- Cet redémarrer les tailtravaux bien, cependant. Et j'ai vérifié que le fichier journal n'est pas tourné en cours de route (ce qui peut faire tailperdre la raison).

Qu'est-ce qui provoquerait cela? J'utilise RHEL 5.2 x64.


Cela se produit-il sur tous les fichiers journaux, ou seulement sur certains? Sur quel système de fichiers se trouve le fichier journal? Quelle application écrit le fichier journal? Avez-vous chronométré l'échec pour voir si cela se produit (1) un certain laps de temps après avoir démarré la commande tail; ou (2) à certains intervalles fixes (par exemple toujours à: 00: 10: 20: 30: 40 et: 50 après l'heure)?
daveadams

@daveadams - pour autant que je l'ai remarqué, il n'a été que sur deux (un sur chacun des deux serveurs): dans ce cas, le fichier journal de dataminer pour BSAE (outil de reporting) sur un serveur HPSA Core (automatisation du centre de données) et le server.log pour BSAE sur l'hôte déclarant
warren

1
en passant, tail -F continuera de fonctionner même si le fichier est supprimé et remplacé plus tard par un autre fichier entièrement.
Sirex

Réponses:


6

Essayez d'envelopper votre commande tail avec stracesi vous l'avez:

strace -Tt -o /tmp/tail.trace tail -f /var/log/messages

Ensuite, juste pour les coups de pied récursifs fous, vous pouvez suivre la sortie de strace (peu importe si cela se casse parce qu'il sort dans un fichier):

 tail -f /tmp/tail.trace

Le mien ressemble à:

8:39:00 write(1, "ng SMAC\n", 8)       = 8 <0.000026>
18:39:00 read(3, "", 0)                 = 0 <0.000019>
18:39:00 fstat64(3, {st_mode=S_IFREG|0640, st_size=92990, ...}) = 0 <0.000019>
18:39:00 fstatfs64(3, 84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=4807069, f_bfree=1924458, f_bavail=1680271, f_files=1221600, f_ffree=820806, f_fsid={-1331083162, -1313908385}, f_namelen=255, f_frsize=4096}) = 0 <0.000021>
18:39:00 inotify_init()                 = 4 <0.000033>
18:39:00 inotify_add_watch(4, "/var/log/messages", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1 <0.000041>
18:39:00 fstat64(3, {st_mode=S_IFREG|0640, st_size=92990, ...}) = 0 <0.000019>
18:39:00 read(4,

-T active le temps et -T active le temps passé dans les appels.

Appuyez sur le retour 4 ou 5 fois pour créer un peu d'espace vertical, puis attendez qu'il cesse de fonctionner. Espérons qu'il y aura quelques indices dans la sortie.


9

Essayez d'utiliser:

tail --follow=name <logfile>

Et voyez si cela fonctionne mieux. Vous n'avez pas à vous soucier de sa rotation sous vous.


Un motif qui s'arrête? Certaine durée? Une certaine heure de la journée?


le fichier n'est pas en rotation par le bas tail- c'est juste périodiquement (entre 2 et 20 heures) qui s'arrête de suivre plus. J'aimerais qu'il y ait plus d'un modèle: - \
warren

Si vous appuyez sur d'autres touches du clavier (autres que ctrl-c), cela s'améliore-t-il? Quand il s'arrête, vous pouvez essayer de vous y attacher en utilisant strace / ltrace / etc. pour voir si ça fait quelque chose.
MikeyB

bonne réflexion sur la strace - ni entrer ni les autres touches ne produisent quoi que ce soit; J'aime parfois laisser un tail-f en cours de screensession pour un débogage prolongé, et c'est inquiétant
warren

1
Ah… peut-être pas votre problème, mais assurez-vous de ne pas laisser accidentellement une fenêtre d'écran ouverte en mode copie avec tail -f en cours d'exécution. Le mode copie rendra éventuellement le bloc de sortie de la commande (lorsque le tampon se remplira).
MikeyB

Excellente réponse. Bien sûr, mes fichiers tournaient en haut de chaque heure!
alex

4

Étant donné que les deux fichiers journaux problématiques sont écrits par différents composants de la même application, je me demande si ce n'est pas une partie du code de journalisation de cette application qui cause le problème. Je propose deux tests pour avoir une meilleure idée de ce qui se passe:

  • Notez l'inode du fichier journal ( ls -i logfile) avant de démarrer la queue, et une fois que la queue échoue, vérifiez-la à nouveau. Si l'inode a changé, l'enregistreur réécrit l'intégralité du fichier journal, ce qui romprait la connexion de la queue.

  • Notez la dernière ligne avant que tail cesse de fonctionner, puis visitez le fichier et recherchez la première entrée de journal après cette ligne. Faites cela 3-5 fois si possible. S'il s'agit d'un problème avec le programme effectuant la journalisation, la partie du programme qui a écrit l'entrée de journal immédiatement après que vous voyez une rupture de queue est très probablement responsable. Si cette entrée de journal est toujours la même, ou si elle provient du même composant du programme, vous pouvez avoir suffisamment de données pour soumettre un rapport de problème au fournisseur de l'application.

Bonne chance.


3

Avoir le même problème ici.

Le problème était que le fichier que je regardais était monté à partir d'une autre machine. La notification de modification n'a pas été propagée via le montage.

La solution était d'utiliser la queue sur la machine d'origine.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.