Log file "/var/log/icinga2/compat/icinga.log" invalid! No timestamp found within first 16 bytes

This forum was archived to /woltlab and is now in read-only mode.
  • Hallo,


    wenn ich Menü "Reporting" mir die Notifications anschauen möchte, erhalte ich die Fehlermeldung "Log file "/var/log/icinga2/compat/icinga.log" invalid! No timestamp found within first 16 bytes!". Das Versenden der Notification funktioniert per Mail wie auch per SMS, nur die Anzeige in der ClassicUI gibt den Fehler aus. Wenn ich mir dann das vergangene Jahr anzeigen lasse, dann sehe ich wieder Einträge wie erwartet, aber nur bis zum 06.09.. Ungefähr 30 Minuten vor der letzten Eintrag in den Notification sehe ich im apt History Log das Update von Version 2.4.10-1~debmon8+1 auf 2.5.4-1~debmon8+3, am 09.09. dann auf Version 2.5.4-1~debmon8+4.



    Code
    1. # dpkg -l | grep icinga
    2. ii icinga-cgi-bin 1.13.3-1~debmon80+1 amd64 host and network monitoring system - CGI scripts
    3. ii icinga2 2.5.4-1~debmon8+4 amd64 host and network monitoring system
    4. ii icinga2-bin 2.5.4-1~debmon8+4 amd64 host and network monitoring system - daemon
    5. ii icinga2-classicui 2.5.4-1~debmon8+4 all host and network monitoring system - classic UI
    6. ii icinga2-common 2.5.4-1~debmon8+4 all host and network monitoring system - common files
    7. ii icinga2-doc 2.5.4-1~debmon8+4 all host and network monitoring system - documentation
    8. ii icinga2-ido-mysql 2.5.4-1~debmon8+4 amd64 host and network monitoring system - MySQL support
    9. ii libicinga2 2.5.4-1~debmon8+4 amd64 host and network monitoring system - internal libraries


    Wenn ich mir allerding das icinga.log anschaue, dann sehe ich aktuelle Uhrzeiten in den ersten 16 Bytes.

    Code
    1. head -n4 /var/log/icinga2/compat/icinga.log
    2. [1474880400] LOG ROTATION: HOURLY
    3. [1474880400] LOG VERSION: 2.0
    4. [1474880400] CURRENT HOST STATE: BF5WA;UP;HARD;1;PING OK - Packet loss = 0%, RTA = 0.75 ms
    5. [1474880400] CURRENT HOST STATE: BF5WB;UP;HARD;1;PING OK - Packet loss = 0%, RTA = 1.08 ms
    Code
    1. icinga2 feature list
    2. Disabled features: gelf icingastatus ido-mysql influxdb livestatus opentsdb syslog
    3. Enabled features: api checker command compatlog debuglog graphite mainlog notification perfdata statusdata


    Diese Meldung zieht sich auch durch alle Instanzen durch, der Hauptcluster wie auch ein Satelliet mit GUI haben dieses Problem. Kennt jemand die Ursache oder eine Lösung dafür? Ich würde gerne wieder ohne ewige Loganalysen die versendeten Nachrichten durchschauen können... :(


    Vielen Dank schon mal im Voraus!

  • Wir haben das gleiche Problem. Seit dem Update auf 2.5.4 schreibt icinga2 die Logfiles nach /var/log/icinga2/compat ohne World-Read-Rights:


    Shell-Script
    1. root@icinga2a:/var/log/icinga2/compat# ls -al
    2. insgesamt 2192
    3. drwxr-s--x 3 nagios adm 4096 Sep 27 09:50 .
    4. drwxr-s--- 4 nagios www-data 4096 Sep 27 06:25 ..
    5. drwxr-sr-x 2 nagios adm 151552 Sep 27 06:59 archives
    6. -rw-rw---- 1 nagios adm 2076882 Sep 27 11:05 icinga.log

    Und damit darf der www-data icinga.log und auch die ins archives verschobenen Dateien nicht lesen und liefert die o.a. Fehlermeldung.


    Die quick&dirty-Lösung ist, www-data (oder unter welchem User auch immer Dein Apache läuft) in die adm-Gruppe aufzunehmen(apache dann einmal neu starten), aber das ist eigentlich sicher nicht gewünscht.


    Ich denke, das ist schon ein Bug, den es zu fixen gilt.


    Ciao,
    Patric

  • Vielen, Vielen Dank!


    Da der Workaround funktioniert, kann ich damit leben, so dirty ist die Lösung auch nicht, wenn man sieht wie bösartig die Verzeichnisrechte neuerdings gesetzt sind.

    Code
    1. ls -ld /var/log/icinga2/compat
    2. drwxr-s--x 3 nagios adm 4096 Sep 26 15:59 /var/log/icinga2/compat

    Das macht echt wahnsinnig Sinn, Others darf das Verzeichnis öffnen, aber nicht lesen ;(
    Auf die Berechtigungen im Dateisystem als Fehlerursache wäre ich echt nicht gekommen...

    Code
    1. so sah es mal aus:
    2. -rw-r--r-- 1 nagios adm 5135512 Nov 30 2015 icinga-11-30-2015-11.log
    3. so sieht es jetzt aus:
    4. -rw-rw---- 1 nagios adm 8406489 Sep 19 12:59 icinga-09-19-2016-13.log
  • Hallo,


    ich habe das gleiche Problem bei mir.

    Ich habe www-data in die adm-Gruppe aufgenommen.

    Allerdings erhalte ich bei den archivierten logs immer noch den Fehler Log file "/var/log/icinga2/compat/archives/icinga-01-19-2017-15.log" invalid! No timestamp found within first 16 bytes!

    Die Rechte habe ich gesetzt.


    Was kann hier noch die Ursache sein?


    Gruß Oliver




  • Der Inhalt schaut identisch mit der icinga.log unter /var/log/icinga2/compat aus.

    Diese liest er auch ein, aber nicht die im archives


    [1484834400] CURRENT HOST STATE: apollo;UP;HARD;1;PING OK - Packet loss = 0%, RTA = 17.57 ms


    [1484834400] CURRENT HOST STATE: aldi-dfue;UP;HARD;1;PING OK - Packet loss = 0%, RTA = 0.34 ms


    [1484834400] CURRENT HOST STATE: asa-hal;UP;HARD;1;PING OK - Packet loss = 0%, RTA = 0.39 ms


  • Ok, dann liegt es aber definitiv an den Permissions. Vielleicht nicht nur an der Datei selbst, sondern auch am Pfad "archives/". Probier mal mit sudo -u www-data cat <pfadzurdatei> ob du das als Apache-User überhaupt anzeigen darfst.


    .oO(Ich werde froh sein, wenn die Classic UI ausstirbt.)

  • Scheinbar liegt es an den Berechtigungen.

    Aber eigentlich passt das.

    Ich werde es mir morgen nochmal ansehen.


    Danke erstmal.

  • Ich weiß nicht, wer in der adm-Gruppe ist, aber eigentlich sollte es reichen, anstatt "adm" als Gruppe "www-data" (bzw. die Gruppe, zu der der Web-Prozess gehört) einzutragen. Der Monitoring-Prozess ("nagios", "icinga", ...) schreibt die Informationen in die Log-Dateien, die Web-GUI liest die Daten.

  • Ich habe www-data in die adm Gruppe aufgenommen.


    In /var/log/icinga2/compat/ funktioniert es auch, nur nicht in /var/log/icinga2/compat/archives.

  • und wie sehen da die berechtigungen für die files und den ordner aus

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Problem gefunden.

    Die Gruppe hatte kein ausführen Recht auf das Verzeichnis.


    Danke.