Discussion :

[Invité]

Bonjour
je suis en train d'élaborer un script Bash dont voici le principe :
J'ai un process en tache de fond dont la sortie est redirigée sur un fichier sortie.log
Un job Cron analyse la fin ce fichier avec la commande tail -n 1000 sortie.log | grep ....

Le problème c'est que plus mon fichier sortie.log est long (plusieurs Mo), plus le "tail -n 1000" prends du temps, et il fini par durer trop longtemps (j'execute le script sur une plateforme Atheros AR9330 avec un proc à seulement 400 MHz)

Quel serait l'astuce pour transformer en une sorte de FIFO de taille limitée mon fichier sortie.log (les premières lignes étant traitées, je n'en ai plus besoin) et faire en sorte que mon tail -n soit ainsi toujours rapide

Voila, si ce n'est pas assez clair, dites moi, je compléterai.

merci en tout cas

[Flodelarab]

Bonjour,

J'ai du mal à croire que le tail prenne du temps. Dans l'exemple que tu donnes, le tail est le premier élément d'une conduite (enchaînement de commandes séparées par des pipes). Ne serait-ce pas les commandes suivantes qui prennent du temps?

[jack-ft]

Un job Cron analyse la fin ce fichier avec la commande tail -n 1000 sortie.log | grep ....

Et si, entre 2 cron, plus de 1000 lignes ont été générés, on ignore celles qui sont sautées?

ça paraît un peu bizarre comme manière de faire.

Quel serait l'astuce pour transformer en une sorte de FIFO de taille limitée mon fichier sortie.log (les premières lignes étant traitées, je n'en ai plus besoin) et faire en sorte que mon tail -n soit ainsi toujours rapide

Il me semble que la commande tail -f (lecture en continu du fichier) est toute indiquée pour ce genre de job!

[Invité]

Bonjour,
J'ai du mal à croire que le tail prenne du temps. Dans l'exemple que tu donnes, le tail est le premier élément d'une conduite (enchaînement de commandes séparées par des pipes). Ne serait-ce pas les commandes suivantes qui prennent du temps?

Si si, j'ai testé "à la main" la commande, plus le fichier est gros, et plus elle prends de temps

Et si, entre 2 cron, plus de 1000 lignes ont été générés, on ignore celles qui sont sautées?
ça paraît un peu bizarre comme manière de faire.

C'est vrai, j'ai fixé à 1000 comme ça, mais c'est pas terrible.

Il me semble que la commande tail -f (lecture en continu du fichier) est toute indiquée pour ce genre de job!

Oui mais ça ne règlerai pas le problème de la taille de mon fichier sortie qui va ne fera que grandir (problème de stockage)

La sortie de mon programme en tâche de fond est constituée de lignes horodatées, qu'il faut vérifier et parser pour stockage en base de données.
Chaque minute mon cron lance un bash qui sélectionne parmis les 1000 dernières lignes de mon fichier sortie les lignes horodatées à T-1 minute avec un grep puis il parse le résultat avec une boucle while read IFS

Ca fait peut être un peu bricolage mais j'ai pas vraiment trouvé d'autre moyen.

[disedorgue]

Bonjour,

Pour pouvoir aider, il faudrait nous montrer ton script ainsi qu'un bout de log si c'est possible.

Moi, ce que je ne comprends pas c'est l'utilité de la crontab...

[frp31]

tu peux tout à fait utiliser un FIFO pour ça ....

ton cron appelle un script au lieu du tail

ton script vérifie le FIFO si il existe pas il le crée (/dev/fifo par exemple)



par exemple j'utilise ça pour compresser à la volée des volumes trop important qui ne peuvent pas etre un simple programme > fichier.log quand je manque de place mais que j'ai un besoin absolu de garder le log de l'action en cours.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
mknod /dev/MADONA_pipe_export p 
   # creer le FIFO
cat /dev/MADONA_pipe_export | /usr/bin/compress > $REP_SAVE/MADONA$DATE.log.Z & 
   #lire le contenu du fifo et le renvoyer dans le fichier
programme 2>&1 /dev/MADONA_pipe_export 
   # compresse le log à la volée.

[Invité]

@frp31
Je viens d'expérimenter, un tube nommé et je n'ai plus de souci de place ou de rotation.

Merci pour le coup de main.