Unerklärliches Verhalten beim Live-Mittschnitt mit tail cut und grep
Matthias Dort
ich habe ein mir nicht erklärliches Phänomen:
tail -f /var/log/lcdbach | cut -b 1-100 | grep --invert-match \
-f nicht_matchen
bringt keine (nie eine) Ausgabe.
Ohne den "liveschalter" funtioniert es:
tail /var/log/lcdbach | cut -b 1-100 | grep --invert-match \
-f nicht_matchen
----------------- cut -------------------------
Jan 9 12:50:53 lcdbach ADMIN_INFO: Bridge module disabled
Jan 9 12:50:53 lcdbach SYSTEM_INFO: x509_read_from_minifs:
File /minifs/vpn_devcert not found
Jan 9 12:50:53 lcdbach SYSTEM_INFO: x509_read_from_minifs:
File /minifs/vpn_rootcert not found
Jan 9 12:50:53 lcdbach SYSTEM_INFO: PKCS12_lcos_read_file:
File /minifs/vpn_pkcs12_int not found
Jan 9 12:51:21 xxxxxxxxxxxxxxxx PACKET_INFO: Dst: 192.168.3.2:110
{mail.xxxxxxxxxxxxxx.de}, Src: 19Jan 9 12:51:22 lcdbach PACKET_INFO: Dst:
192.168.13.253:53, Src: 192.168.10.1:57370 {lcdbach} (UDP)Jan 9 12:51:22
lcdbach1.xxxxxxx PACKET_INFO: matched filter: INT2EXT
----------------- cut -------------------------
In der Datei "nicht_matchen" stehen die Suchbegriffe.
Letztendlich soll eine Logdatei live beobachtet werden, dabei sind nicht
interessierende Begriffe durch "nicht_matchen" ausgeschlossen und die
Ausgabe soll der Lesbarkeit halber auf 100 Stellen begrenzt werden. Das
entsprechende Terminal macht dann keine Zeilenumbrüche.
Jemand ne Idee?
Gruß
Matthias
Werner Flamme
> Hallo,
>
> ich habe ein mir nicht erklärliches Phänomen:
>
> tail -f /var/log/lcdbach | cut -b 1-100 | grep --invert-match \
> -f nicht_matchen
>
> bringt keine (nie eine) Ausgabe.
Wie denn auch? tail -f wird doch nie beendet, also kann es doch auch
keine Ausgabe pipen... Deshalb funktioniert tail allein, denn es wird ja
beendet :-)
Gruß
Werner
--
Werner Flamme, Abt. WKDV
Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Permoserstr. 15 - 04318 Leipzig
Tel.: (0341) 235-1921 - Fax (0341) 235-451921
http://www.ufz.de - eMail: werner...@ufz.de
Achim Peters
> Matthias Dort [09.01.2009 13:02]:
>> Hallo,
>>
>> ich habe ein mir nicht erklärliches Phänomen:
>>
>> tail -f /var/log/lcdbach | cut -b 1-100 | grep --invert-match \
>> -f nicht_matchen
>>
>> bringt keine (nie eine) Ausgabe.
>
> Wie denn auch? tail -f wird doch nie beendet, also kann es doch auch
> keine Ausgabe pipen...
Das ist vielleicht unter dem Billig-Unix-Imitat Windows der Fall. Unter
Unix kann ein Prozess pipen, auch wenn er nicht beendet wird, und wir
sind hier in dco*u*s.
lpar1:/home/peters$ cat loop.sh
while true
do
echo 1
sleep 1
done;
lpar1:/home/peters$ loop.sh
1
1
1
^Clpar1:/home/peters$ loop.sh | more
1
1
1
1
...
Bye
Achim
Juergen P. Meier
Die Puffer der Pipe sind zu gross fuer deine Daten.
Tail liefert erst dann output an die Pipe, wenn der Puffer gefuellt
wurde.
Diese Puffergroesse ist irgendwas zwischen 512byte (POSIX Minimum) und
je nach OS irgendwelche kilobytes. Linux <2.6.11 hat z.B. 4096 Byte,
neuere KErnels 64kbyte.
D.h. cut sieht erst dann Daten von tail, wenn diese die puffergroesse
erreicht haben.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Matthias Dort
das kommt davon, wenn man eben nicht lange genug wartet .. ;-)
Es funktioniert genau so, wie von Dir beschrieben. Die Ausgabe kommt halt
nur entsprechend verzögert.
Vielen Dank allen die geantwortet haben!
Matthias
Steffen Schuler
> [...]
>
> tail -f /var/log/lcdbach | cut -b 1-100 | grep --invert-match \
> -f nicht_matchen
>
> bringt keine (nie eine) Ausgabe.
Nachdem andere das Problem erklaert haben, hier eine Loesung:
tail -f /var/log/lcdbach |
gawk '{ print substr($0, 1, 100); fflush() }' |
grep -v -f nicht_matchen
fflush() "spuelt" den Standard Ausgabe Puffer von gawk "aus".
Ansonsten macht dieser gawk-Kode dasselbe wie dein cut-Befehl.
>
> Matthias
--
Steffen
Achim Peters
Aber ist nicht das Problem (auch) beim Ausgabe-Puffer von tail? gawk hat
dann ja gar nichts, was er flushen könnte, weil er noch nichts
ausgegeben hat, weil noch nichts reinkam (bis der Ausgabe-Puffer von
tail voll ist).
Bye
Achim
Steffen Schuler
> Steffen Schuler schrieb:
>> [...]
>>
>> tail -f /var/log/lcdbach |
>> gawk '{ print substr($0, 1, 100); fflush() }' |
>> grep -v -f nicht_matchen
>>
> Aber ist nicht das Problem (auch) beim Ausgabe-Puffer von tail? gawk hat
> tail voll ist).
Das Problem ist auch beim Ausgabe-Puffer von gawk.
Wenn durch "tail -f" und das nachgeschaltete gawk der Ausgabepuffer von
gawk nur teilweise gefuellt ist, kann durch fflush() ein "Ausspuelen"
des gawk-Puffers bewirkt werden, ohne vorher auf weitere Eingabe von
"tail -f" zu warten.
Eine bessere und allgemeine Loesung (unbuffer aus dem expect-Paket
angewendet auf "tail -f") wird auf folgender Web-Seite vorgeschlagen:
http://wooledge.org:8000/BashFAQ/009
>
> Bye
> Achim
--
Steffen
Christian Weisgerber
> Die Puffer der Pipe sind zu gross fuer deine Daten.
> Diese Puffergroesse ist irgendwas zwischen 512byte (POSIX Minimum) und
> je nach OS irgendwelche kilobytes. Linux <2.6.11 hat z.B. 4096 Byte,
> neuere KErnels 64kbyte.
Das hat nichts mit dem Kernel zu tun, das ist die Userland-Pufferung
von stdio (libc).
--
Christian "naddy" Weisgerber na...@mips.inka.de
Sven Mascheck
> Eine bessere und allgemeine Loesung (unbuffer aus dem expect-Paket
> angewendet auf "tail -f") wird auf folgender Web-Seite vorgeschlagen:
>
> http://wooledge.org:8000/BashFAQ/009
Dort auch erwähnt: GNU grep kennt '--line-buffered'.
Mit der dort erwähnten Version 2.5.1 wurde es übrigens eingeführt.
Das gibt es zwar schon eine Weile, aber ich finde immer noch Linuxe
mit älteren Versionen.
Für allgemeine Fälle gibt es (für Systeme, die LD_PRELOAD kennen),
noch einen anderen Weg. Zum Beispiel falls man nicht die Möglichkeit
oder den Willen hat, für unbuffer das ganze Paket expect zu installieren.
Hier als Beispiel auf Linux
$ cat unbuffer.c
/*
* linux$ gcc -fpic -c unbuffer.c; ld -shared -o libunbuffer.so unbuffer.o
* solaris$ cc -Kpic -c unbuffer.c; ld -G -o libunbuffer.so unbuffer.o
*/
#include <stdio.h>
void _init() {
setbuf(stdout, NULL);
}
$ cat $HOME/bin/unbuffer
#!/bin/sh
LD_PRELOAD=$HOME/lib/libunbuffer.so export LD_PRELOAD
exec "$@"
$ while sleep 1; do echo x; done|unbuffer grep x|unbuffer grep x|grep x
Insbesondere bei Logdateien mit vergleichsweise seltenen Ereignissen,
auf die ich eine ganze Kette von Filtern (grep/sed/etc) losließ,
war mir eine unbuffer-Möglichkeit schon sehr angenehm.
Sven Mascheck
> Dort auch erwähnt: GNU grep kennt '--line-buffered'.
...wie mittlerweile auch die drei bekanntesten BSDs.
Angenehm, weil einem das Problem bei grep wohl am
häufigsten begegnet, es bleibt aber ein Spezialfall.
Ich bin mir gar nicht sicher, wie eine ideale Lösung aussehen sollte.
Oder ist es schlicht das Tool unbuffer selbst oder ließe sich das
theoretisch noch grundlegender / ganz anders lösen?
- Utility-Options sind es ja wohl nicht ("do one thing and do it well").
- LD_PRELOAD scheint mir da sogar näher dran, shared libs sind aber
natürlich viel zu speziell; ganz zu schweigen davon, daß man einen
Compiler benötigt.
- Ein Interface a la "stty"?
Juergen P. Meier
> Juergen P. Meier <nospam-re...@jors.net> wrote:
>
>> Die Puffer der Pipe sind zu gross fuer deine Daten.
>> Diese Puffergroesse ist irgendwas zwischen 512byte (POSIX Minimum) und
>> je nach OS irgendwelche kilobytes. Linux <2.6.11 hat z.B. 4096 Byte,
>> neuere KErnels 64kbyte.
>
> Das hat nichts mit dem Kernel zu tun, das ist die Userland-Pufferung
> von stdio (libc).
Bei Linux orientiert das GLIBC-Userland nah am Kernel.