Re: toujours tail
Juste une clarification: I wrote: > Et en plus avec celui là tu ne peux pas louper de lignes C'était par rapport au script en ksh de Daniel (pas par rapport au tail -f | grep_en_perl proposé par Marc) Nicolas -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
Hello, Marc SCHAEFER wrote: > > [...] > > > Par contre, avec Perl, si, je sais faire, et comme Perl est un excellent grep: Un tail aussi en plus: (cf man perlfunc fonction seek) surtout le seek(L,0,CUR_POS) pour clearer l'eof ;) #!/usr/bin/perl open(L, "; print "Alarm\n" if ($l =~ /su/); } Et en plus avec celui là tu ne peux pas louper de lignes et il est très efficace et consomme peu de ressources. Nicolas -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
On Thursday 25 October 2001 16:31, Marc SCHAEFER wrote: > On Thu, 25 Oct 2001, Marc SCHAEFER wrote: > >tail -f fichier | grep quelque_chose > > J'ai oublié de dire que si l'on redirige, il n'y aura pas buffering > ligne-à-ligne, mais avec un plus grand buffer (p.ex. 512 bytes ou plus, je > n'ai pas en tête). > Autre point : Attention avec NFS... les règles de buffereing que l'on arrive à déterminer en "local" risquent d'être complètement chamboulées avec NFS. Ceci est aussi valable lors de l'usage de sokects. Par exemple, lors de l'usage d'un rlogin/rsh, les lignes parraissent arriver entières mais ce n'est que rarement le cas. Toutefois, à l'échelle d'un shell, et en batch, il n'y a pratiquement aucune chance que ça pose des problèmes. Mais suivant ce que tu fais derrière... Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
On Thu, 25 Oct 2001, Marc SCHAEFER wrote: >tail -f fichier | grep quelque_chose J'ai oublié de dire que si l'on redirige, il n'y aura pas buffering ligne-à-ligne, mais avec un plus grand buffer (p.ex. 512 bytes ou plus, je n'ai pas en tête). Tout cela c'est la bibliothèque C standard: si stdout est un tty (terminal), buffering par défaut ligne, sinon `block'. Cf man setvbuf(3) pour le faire en C. Exemple: xterm_1% cat > abcd xterm_2% tail -f /tmp/abcd | grep turlututu > fichier # mode block! xterm_3% tail -f fichier A voir, grep, sauf si connecté à un terminal, fait du buffering plus que ligne-à-ligne. C'est un comportement qui ne *correspond* pas au comportement usuel des programmes sous UNIX, qui ne bufférisent pas quand ils sont face à un pipe, probablement pour optimisation: la preuve c'est que le tail, lui, passe les données: schaefer@defian:~% ps auxw | grep grep schaefer 3670 0.0 0.3 1112 428 pts/7S16:22 0:00 grep turlututu schaefer@defian:~% strace -p 3670 read(0, "abcd\n", 32768)= 5 read(0, "turlututu\n", 32768) = 10 read(0, "turlututu\n", 32768) = 10 [ tail passe, grep bufférise ] Symptôme: seulement si on tape énormément dans xterm_1 on a la sortie dans xterm_3, avec un BUF_SIZE de décalage. Solution: forcer `grep' à changer le buffering, ie passer à ligne-à-ligne, ou `no buffering'. Je l'avoue, je ne sais pas faire, même après un grep rapide dans le manuel et le info. Et je n'ai pas le temps de RTFS aujourd'hui. Par contre, avec Perl, si, je sais faire, et comme Perl est un excellent grep: #! /usr/bin/perl -w use strict; $| = 1; # no buffering while (<>) { if (/turlututu/) { print; } } Le seul changement à apporter: xterm_2% tail -f /tmp/abcd | ./machin.pl > /tmp/fichier Je te laisse soin de modifier le programme pour que la regexp soit passable par argument. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
On Thu, 25 Oct 2001, Yann Sagon wrote: > Le scénario est le suivant: c'est un fichier qui n'est pas en local (il est > en nfs) et on ne peut pas utiliser syslog pour le rediriger sur un pipe... SyslogD est capable de déclancher des process s'il le faut, tu peux passer pas ssh, si tu veux... De plus il est conçu pour une architecture réseau et logs distribués... (man: syslog.conf, syslog, syslogd, logger) > est ce que je peux quand même m'en sortir comme ça? M'est avis que tu ne prend pas le problème dans le bons sens... Comme lorque je rédige un texte et que je n'arrive pas à trouver un mot pour terminer une phrase, parfois la solution est de réécrire toute la phrase, différemment... -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
> ==> coup de bol. on a notre fichier. > Oui, mais bon:) dans ce cas, autant ne pas utiliser -f (tail -f) et relancer tail tout le temps:) Oui, donc, il faut que ce tail marche tout le temps en background pour qu'un autre programme puisse tripoter le fichier de résultat... Mais merci quand même pour l'idée! Yann Sagon > > > > -- > http://www-internal.alphanet.ch/linux-leman/ avant de poser > une question. Ouais, pour se désabonner aussi. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
On Thursday 25 October 2001 15:01, Yann Sagon wrote: > > Que veux tu dire.. il s'arrete pour toujours, ou il fait une pause.. ? > Dans les cas 1 & 2 il fait une pause (stoped). Dans le cas 3, y'a plus d'process. > > À part ça, si tu veux être capable de "raccrocher" au log, tout en > > traitant > > Désolé, mais je ne vois pas non plus ce que tu veux dire par "raccrocher" > !!! C'est à dire que tu démarre ton machin longtemps après que le log ait commencé à se remplir, que tu veux traiter ce qu'il contien déjà mais qu'une fois que tu es arrivé à la dernière ligne du fichier, tu veux traiter ce qui continue d'arriver de manière sporadique. > Le scénario est le suivant: c'est un fichier qui n'est pas en local (il est > en nfs) et on ne peut pas utiliser syslog pour le rediriger sur un pipe... > est ce que je peux quand même m'en sortir comme ça? Tu peux faire tourner ton grep sur la machine remote, te créer un socket... ou encore (attention les vélos, ça va raper... c'est du ksh... plus simple pour les opération arithmétiques) integer n { (( n=$(wc -l 10 )) then (( n=n-10 )) sed -n "1,${n} p" /var/log/truc_chose fi tail -f /var/log/trux_chose } 2>&1 | grep "blabla" >>text.tmp Ça, c'est pour lire le le fichier de log jusqu'à Last_Line - 10, balancé ces lignes sur stdout, puis reprendre le reste des lignes et ce qui arrivera par par la suite (c'est ce que j'appelle "raccrocher") et le balancer aussi sur stdout. L'ensemble du stdout (et stderr, quoique je n'en vois pas l'utilité) est ensuite traité par ton grep... Bon, y'a un "trou"... si jamais un nouveau message arrive entre le moment du wc et le sed... risque de perdre une ou plusieurs lignes... Aussi, considère que ce script n'est pas le résultat de deux jours de réflexion mais plutôt une idée "comme ça" qui peut t'éclairer sur les possibilités de ce genre de traitement à l'aide de ksh (c'est la partie didactique). Pourquoi ksh ? Pour rire un coup... parceque ça marche partout et que c'est relativement compréhensible. Ça peut aussi se faire en Perl (certainement encore plus compact), awk, PHP, Latex, PostScript, ... Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
On Thu, 25 Oct 2001, Yann Sagon wrote: > en nfs) et on ne peut pas utiliser syslog pour le rediriger sur un pipe... syslog marche par réseau de syslog à syslog, et cela doit donc être possible de finalement passer par une pipe. > est ce que je peux quand même m'en sortir comme ça? Essayons: Pour que cela: tail -f fichier | grep quelque_chose fonctionne dans le cas général, il faut que ni tail ni grep ne fasse de buffering. schaefer@defian:/tmp% touch abcd schaefer@defian:/tmp% tail -f abcd | grep turlututu après avoir rapidement essayé (du moins en local), chez moi ça marche (depuis un autre terminal j'ai fait: echo turlututu >> /tmp/abcd. Cela ferme le fichier, j'ai donc utiliser cat >> /tmp/abcd sans taper CTRL-D. Il y a un délai mais c'est normal, cf plus bas). Comment ça marche ? schaefer@defian:~% ps auxw | grep tail schaefer 3255 0.0 0.2 1012 380 pts/6S15:02 0:00 tail -f abcd schaefer@defian:~% strace -p 3255 fstat(3, {st_mode=S_IFREG|0644, st_size=1577983, ...}) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, {1, 0}) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=1577983, ...}) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, {1, 0}) = 0 en bref, chaque seconde, tail regarde le mtime du fichier via fstat et si oui il fait une lecture jusqu'à la fin. En 2.4 ont été implémentées des interfaces de notification (ie: push plutôt que pull -- ou le contraire :)) similaire à ce qui existait sur SGI IRIX. Enfin je crois, pas encore essayé. Donc, cela peut aider si tes machines (en NFS) ont le temps synchronisé. NB: pour que syslog écrive effectivement immédiatement dans le fichier, il faut, comme décrit dans man 5 syslog.conf, que l'entrée correspondante n'ait pas de `-'. En plus, par réseau il y aura forcément caching. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
RE: toujours tail
> > tail -f /var/log/unlog | grep "blabla" >> test.tmp 2>&1 & > > > > ça a l'air de marcher.. > > > tiens.. non.. en fin de compte, ça ne marche pas:((( > > Si quelqu'un à une idée, merci beacoup!!! J'ai pas la solution, juste une idee. [j'suis en root mais rien a voir avec le probleme ] Voici: [root@pingu log]# tail -f /var/log/messages Oct 25 14:50:56 pingu PAM_pwdb[7581]: (login) session opened for user jeanluc by (uid=0) Oct 25 14:50:56 pingu login[7581]: LOGIN ON ttyp3 BY jeanluc FROM WS_JEANLUC_J Oct 25 14:50:56 pingu PAM_pwdb[7581]: (login) session closed for user jeanluc ==> y'a bien des messages qui viennent. On peut faire des trucs. [root@pingu log]# tail -f /var/log/messages | grep WS_JEANLUC_J >/root/monLogTri.txt ==> cette console est bloquee: normal, ca tourne. [root@pingu /root]# ps -aux root 7596 0.4 2.5 812 376 p1 S14:52 0:00 tail -f /var/log/messages root 7597 0.5 3.0 928 440 p1 S14:52 0:00 grep WS_JEANLUC_J ==> il a fait deux process qui sont pipes l'un vers l'autre [root@pingu /root]# ls -la |grep Tri -rw-rw-r-- 1 root root0 oct 25 14:52 monLogTri.txt ==> le fichier existe. En cours d'ecriture. dans un buffer quelque part sans doute? un Ctrl+c ferait que le fichier reste a 0 octet et le resultat du fichier est perdu a jamais. ==> Ctrl+c = pas bon [root@pingu /root]# kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGIOT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH29) SIGIO 30) SIGPWR ==> voyons voir les signaux plus sympatiques que ce fameux Ctrl+c SIGHUP est en general moins mechant que les autres. [root@pingu /root]# kill -1 7596 [root@pingu /root]# cat monLogTri.txt Oct 25 14:32:15 pingu login[7516]: LOGIN ON ttyp2 BY jeanluc FROM WS_JEANLUC_J Oct 25 14:36:14 pingu login[7538]: LOGIN ON ttyp3 BY jeanluc FROM WS_JEANLUC_J Oct 25 14:50:56 pingu login[7581]: LOGIN ON ttyp3 BY jeanluc FROM WS_JEANLUC_J ==> coup de bol. on a notre fichier. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
> J'ai pas trop suivi ton problème depuis le début, mais moi j'écrirais : > > tail -f /var/log/unlog 2>&1 | grep "blabla" >>text.tmp > ça ne marche pas non plus.. > tail -f ne s'arrète que dans trois cas : Que veux tu dire.. il s'arrete pour toujours, ou il fait une pause.. ? > > 1 ) Tail pointe déjà à la fin du fichier, il attend la suite > 2 ) le pipe (en sortie) est plein. il attend que le programme de lecture > (grep) vienne lire des bytes pour le vider un peu > 3 ) Tail est interrompu ! > > À part ça, si tu veux être capable de "raccrocher" au log, tout en traitant Désolé, mais je ne vois pas non plus ce que tu veux dire par "raccrocher" !!! > aussi ce qui a été écrit depuis le début, il faut que tu traite le problème > à l'aide d'un "named pipe". Ce qui a, je crois, déjà été expliqué par > Félix. > Le scénario est le suivant: c'est un fichier qui n'est pas en local (il est en nfs) et on ne peut pas utiliser syslog pour le rediriger sur un pipe... est ce que je peux quand même m'en sortir comme ça? > Daniel Yann Sagon -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
On Thursday 25 October 2001 10:30, Yann Sagon wrote: > > maintenant, j'ai trouvé la solution suivante: > > > > tail -f /var/log/unlog | grep "blabla" >> test.tmp 2>&1 & > > > > ça a l'air de marcher.. J'ai pas trop suivi ton problème depuis le début, mais moi j'écrirais : tail -f /var/log/unlog 2>&1 | grep "blabla" >>text.tmp Dans ce cas, c'est le stderr de tail qui est AUSSI redirigé dans le stdout, CAD dans le pipe. tail -f ne s'arrète que dans trois cas : 1 ) Tail pointe déjà à la fin du fichier, il attend la suite 2 ) le pipe (en sortie) est plein. il attend que le programme de lecture (grep) vienne lire des bytes pour le vider un peu 3 ) Tail est interrompu ! À part ça, si tu veux être capable de "raccrocher" au log, tout en traitant aussi ce qui a été écrit depuis le début, il faut que tu traite le problème à l'aide d'un "named pipe". Ce qui a, je crois, déjà été expliqué par Félix. Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
> maintenant, j'ai trouvé la solution suivante: > > tail -f /var/log/unlog | grep "blabla" >> test.tmp 2>&1 & > > ça a l'air de marcher.. > tiens.. non.. en fin de compte, ça ne marche pas:((( Si quelqu'un à une idée, merci beacoup!!! -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
> > Je veux effectuer ça: > > tail -f /var/log/unlog | grep "blabla" >> test.tmp > > > > evidement, ça ne marche pas... > > Hem quoi?! :-P > eh oui!!!:) /var/log/ n'était qu'un exemple. mais oui, j'ai le droit d'écriture/lecture sur les fichiers que j'utilises:) Le problème est que tail -f ne se s'arrête pas (heureusement!) il faut donc l'arrêter avec un control c par exemple. Et dans ce cas, le fichier test.tmp est toujours vide:( maintenant, j'ai trouvé la solution suivante: tail -f /var/log/unlog | grep "blabla" >> test.tmp 2>&1 & ça a l'air de marcher.. > Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch Yann Sagon -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: toujours tail
On Wed, 24 Oct 2001, Yann Sagon wrote: > bonjour, > > j'ai toujours une question: > Je veux effectuer ça: > tail -f /var/log/unlog | grep "blabla" >> test.tmp > > evidement, ça ne marche pas... Hem quoi?! :-P As-tu des messages d'erreur? > > ni tail -f /var/log/dmesg | grep "blabla" >> test.tmp & As-tu le droit de lire /var/log... As-tu le droit d'écrire test.tmp Où écris-tu test.tmp -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
toujours tail
bonjour, j'ai toujours une question: Je veux effectuer ça: tail -f /var/log/unlog | grep "blabla" >> test.tmp evidement, ça ne marche pas... ni tail -f /var/log/dmesg | grep "blabla" >> test.tmp & quelqu'un a une idée pour mon petit problème qui doit être très bête mais bon:) Yann Sagon -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.