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 21 ç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
maintenant, j'ai trouvé la solution suivante: tail -f /var/log/unlog | grep blabla test.tmp 21 ç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
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 21 ç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 21 | 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.
calendriers de groupe
Il y a quelque temps, certains cherchaient une solution permettant de gérer les agendas d'un groupe. J'ai trouvé des infos à ce sujet sur le site de SuSe. C'est lié à leur nouveau SuSE Linux eMail Server III. http://www.suse.com/us/press/press_releases/archive01/firewall_III.html Attention, ce n'est PAS une solution Open Source ! Mais, ça tourne sous Linux, c'est bien sécurisé et ce n'est pas plus cher que les pompes à virus d'autres OS... Daniel -- 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 21 | 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.
fichier log radius
Bonjour, est ce que quelq'un a un serveur radius qui tourne? Je cherche un fichier log de radius pour voire son format. Je suis interessé par le fichier qui indique le numéro de tel de l'appelant, le numéro ip attribué etc.. Si vous avez ça, merci de m'en envoyer un petit bout par email:) Yann Sagon -- 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 21 ç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
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
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 /var/log/truc_chose) ))
if (( n10 ))
then
(( n=n-10 ))
sed -n 1,${n} p /var/log/truc_chose
fi
tail -f /var/log/trux_chose
} 21 | 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
== 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 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
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 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
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, /var/log/messages);
# va à la fin du fichier
seek(L,0,2);
while (1) {
while (eof(L)) {
sleep 1;
seek(L,0,1);
}
$l = 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.
