Hallo Fabian,

auch Dir ein Dank für die Ideen.

Ich würd zur manuellen Binärbaumsuche greifen: teile die Datei in zwei Hälften (dd), greppe in beiden nach irgendwas vorhandenem (ein "e"), mit einer matchenden Hälfte wieder von vorn beginnen, bis die Hälfte klein genug ist, dass man es mit bloßem Auge sofort sieht.

Ich bin anders rangegangen aber mit der selben Motivation. Ich habe die Datei im vi offen und sehe zwischen der letzten grepbaren Zeile bis zum ersten Auftreten des Suchstrings im "binären Bereich" eben nichts augenscheinliches. Muss man vi noch befähigen "Sonderzeichen" sichtbar zu machen?

Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8

Hi,

Am Thu, 14 Feb 2019 17:13:00 +0100 schrieb "Ronny Seffner" ronny@seffner.de:

Muss man vi noch befähigen "Sonderzeichen" sichtbar zu machen?

"-b" vermutlich - jedenfalls für vim. Zeigt vim bei mir aber eh auch so an, wie sich vi verhält, weiß ich nicht (Gnade der späten Geburt...)

Ansonsten das bereits erwähnte hexdump, mit -C, ich vermute irgendwo ist da ein NUL byte drin, oder horizontaler Tab oder irgendsowas Verirrtes. Ich hatte neulich ein ähnliches Problem mit Logfiles, kann mich aber gerade absolut nicht daran erinnern, was genau da war, da ich seither leider durch einen Türrahmen gegangen bin und das bei mir immer zu partiellem Gedächtnisverlust führt :/ Mal sehen, obs meinem Kollegen noch einfällt.

Oder, eben gebastelt, schau mal die Häufigkeitsverteilung der Bytes an.

hexdump -v -e '/1 "%02X\t"' -e '/1 "%c\n"' FILE|sort|uniq -c

Der zweite Block nach -e printed das Zeichen noch, das kann aber natürlich die Ausgabe stören je nach Sonderzeichen, ggf. also weglassen, und die seltensten Zeichen voran:

hexdump -v -e '/1 "%02X\n"' FILE|sort|uniq -c|sort -hr

Grüße Carsten

Hallo Ronny,

On Thu, Feb 14, 2019 at 17:04:31 +0100, Ronny Seffner wrote:

...

Um welche Logdateien geht es genau?

Zum Beispiel auth.log, syslog oder auch mail.log. Also alles was durch syslog-ng verwaltet wird.

Hmm, ich kann mich nicht erinnern, dass syslog-ng auf Debian der Default-Syslogserver waere. Eigentlich ist das doch rsyslogd?

ns2:~# file /var/log/syslog /var/log/syslog: ASCII text, with very long lines

Wenn eine Datei nur lang genug ist, erkennt file nicht, wenn sich irgendwo weiter hinten Binaermuell darin befindet. Probeweise habe ich meine /var/log/syslog (aktuell 3 MB) nach /tmp kopiert und in die Kopie ab Offset 1500000 eine Folge von 8000 Nullbytes geschrieben:

$ ls -l syslog -rw-r----- 1 chris chris 3145267 Feb 14 22:58 syslog

$ dd if=/dev/zero of=syslog conv=notrunc bs=1 seek=1500000 count=8000 8000+0 records in 8000+0 records out 8000 bytes (8,0 kB, 7,8 KiB) copied, 0,0191606 s, 418 kB/s

$ file -i syslog syslog: text/plain; charset=us-ascii

Voila, file sagt "ascii", obwohl 8000 Nullbytes drin sind.

Gruss, Christian

On Fri, Feb 15, 2019 at 11:11:18AM +0100, Heiko Schlittermann wrote:

Christian Perle chris@linuxinfotag.de (Do 14 Feb 2019 23:11:11 CET):

...

...

ns2:~# file /var/log/syslog /var/log/syslog: ASCII text, with very long lines

Wenn eine Datei nur lang genug ist, erkennt file nicht, wenn sich irgendwo weiter hinten Binaermuell darin befindet. Probeweise habe ich meine /var/log/syslog (aktuell 3 MB) nach /tmp kopiert und in die Kopie ab Offset 1500000 eine Folge von 8000 Nullbytes geschrieben:

File schaut nur am Anfang nach magic patterns, aus dem Bauch würde ich sagen, daß schon nach ca 1k Schluß ist. Ich weiß nicht, ob es führende binäre Nullen „skippen“ würde, glaube es aber nicht.

man 1 file man 5 magic

da passiert viel "Magie" :-)

Default für die maximale Anzahl an Bytes ist laut der manpage von file 1 MiB, ob aber überhaupt soviel gelesen wird, hängt aber vom Dateityp ab.

In der Definition für libmagic kann man für bestimmte Tests Offsets angeben, wenn die magischen Bytes erst später in einer Datei kommen, für den Fall von oben wird das aber wahrscheinlich nicht helfen. Das Überspringen von Null-Bytes hab ich nicht gefunden.

Viele Grüße Jan

"Bernd Müller" be-mueller@gmx.de (Do 14 Feb 2019 21:20:35 CET):

Das Problem mit den Log-Dateien entsteht, wenn der Prozess Speicher für das Logfile angefordert hat, aber aus irgendeinem Grund dann doch nicht in die Datei schreibt. In diesem Fall werden einfach Null-Bytes in das Logfile

Du meinst, syslog-ng alloziert schon mal genug Platz, um dann anschließend reinzuschreiben? Mit mmap(2), oder einfach direkt im File mit lseek(2)? Das hielte ich für sehr gewagt, weil dann Tools, die am Ende des Logfiles mitlesen möchten, ein Problem hätten.

Ist das ein xfs, was Du da verwendest?

Ich möchte aber lieber wissen, was da warum passiert ist. Ich möchte nicht mitten im Monat die Logs rotieren. Ich kann nicht alle Helfer pauschal auf grep -a umstellen.

Haben diese Files auffällige Größen (irgendwelche Vielfaches von 4k oder so)

-- Heiko