UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Mauflo]

@Homoran ok ich werde das mal versuchen. Aber Verbesserung ist das keine. Das bedeutet, dass man nicht mehr am Server ein Logfile analysieren kann, wenn man mal schnell was nachsehen will. :-(

[Dr. Bakterius]

Ich bin auch nicht begeistert! Nur um etwas Speicherplatz zu sparen verzichtet man hier auf Komfort? Bei den heutigen Speicherpreisen erscheint mir das mehr als unnötig. :confused:

[Homoran]

@Dr-Bakterius sagte in Plötzlich logfiles als .gz files:

Ich bin auch nicht begeistert! Nur um etwas Speicherplatz zu sparen verzichtet man hier auf Komfort? Bei den heutigen Speicherpreisen erscheint mir das mehr als unnötig. :confused:

Das ist jetzt etwas stark aufgetragen!

Was ist an:

@crunchip sagte in Plötzlich logfiles als .gz files:

ein issue erstellt um die Logfiles wieder direkt aufrufen zu können

nicht zu verstehen

[Dr. Bakterius]

@Homoran Weil man hier, meines Erachtens, falsch vorgegangen ist. Es wird bei Problemen immer wieder ein Log-Auszug verlangt. Diesen Zugang zu erschweren ist daher für Problemlösungen suboptimal. Besser wäre es gewesen gleich mit Einführung der komprimierten Log-Files die native Möglichkeit zu schaffen diese über die Weboberfläche - wie bisher - öffnen zu können.

Darüber hinaus verstehe ich immer noch nicht den Sinn oder Nutzen diese paar Files zu komprimieren.

[darkiop]

@Dr-Bakterius sagte in Plötzlich logfiles als .gz files:

Darüber hinaus verstehe ich immer noch nicht den Sinn oder Nutzen diese paar Files zu komprimieren.

Es gängige Praxis dies so zu tun:

Desweiteren funktioniert hier bei mir z.B. mit zless oder lnav (übrigens sehr zu empfehlen!) ohne Probleme.

[Homoran]

@Dr-Bakterius sagte in Plötzlich logfiles als .gz files:

Besser wäre es gewesen gleich mit Einführung der komprimierten Log-Files die native Möglichkeit zu schaffen diese über die Weboberfläche - wie bisher - öffnen zu können.

und das ist der bug - deswegen das Issue

@Dr-Bakterius sagte in Plötzlich logfiles als .gz files:

Es wird bei Problemen immer wieder ein Log-Auszug verlangt.

das aktuelle log ist ja nicht gepackt

[Dr. Bakterius]

@darkiop sagte in Plötzlich logfiles als .gz files:

Es gängige Praxis dies so zu tun

Schon klar. Nur sollte man System-Logs von Anwender-Software-Logs unterscheiden! Vor allem, wenn es bisher so einfach war diese anzuzeigen und für den Support zu kopieren. Jetzt muss man zumindest am Rechner per SSH oder SCP anmelden um die Dateien anzeigen oder downloaden zu können. Ich empfinde das als Rückschritt!

@Homoran sagte in Plötzlich logfiles als .gz files:

das aktuelle log ist ja nicht gepackt

Was wenig hilft wenn man es erst am nächsten Tag braucht. :face_with_rolling_eyes:

Was genau ist denn geplant? Soll man das Log-File lediglich über den Browser downloaden können? Oder soll man es, wie zuvor, im Browser öffnen können?

[cash]

Ich verstehe den Sinn auch nicht warum die Logs auf einmal gepackt werden. Wo ist der Sinn? Früher als Speicher beschränkt war hat man gepackt um Platz zu sparen. Aber heute?

Es ist ja nicht so das man so etwas implementiert wenn man langeweile hat. Es wird also einen guten Grund geben. Da bin ich mir sicher. Und genau deshalb würde mich der Grund interessieren.

[Mauflo]

@cash Nun in der neuen Version ist der Button ganz verschwunden :

So kann man das Problem natürlich auch lösen. Gut finde ich es aber nicht ;-)

[harrym]

Ich verstehe die ganze Aufregung nicht!

Das file .log ist das aktuelle Logfile. Alle Files mit .gz sind ältere.

Wielange ein aktuelles Logfile als .log verfügbar sein soll, kann man einstellen ... auch für 365 Tage (was keinerleii Sinn macht)

Gepackte .gz Files kann mann unter Linux ganz einfach via mc anguggen und unter Windoof mit z.B. WinRar.

Just my 2 cents.

[Mauflo]

@harrym ok dann will ich versuchen es zu erklären: Im Menü LOG hat man manchmal einfach Error oder Warnings und will vielleicht etwas verstehen und/oder kurz analysieren. Bislang konnte man die letzten Tage einfach anklicken und sie öffneten sich als Tab im Browser. Total easy. Nachdem sie gezippt wurden, war das nicht mehr so einfach möglich. Man mußte sie entweder in der Konsole entpacken und ansehen oder eben runterladen und am PC ansehen. Für einen kurzen Blick in die letzten Tage ein Mehraufwand der eben als unpraktisch empfunden wird. Es mag sein, dass es bei Logfile in Linux üblich ist und daher vielleicht als normal gesehen wird. Es war aber einfacher, wenn auch nicht Entwicklerkonform. Übrigens würde mich schon interessieren wo ich einstellen kann wie lange ein Logfile als normales .log file zur Verfügung steht und nicht gezippt wird. Außerdem ist der Button jetzt komplett weg. Ein weiterer Nachteil, denn nach einem Neustart steht unter dem Menü LOG nur mehr jene Info seit dem Neustart im aktuellen Menüpunkt. Um mir das komplette Logfile anzusehen, bin ich wieder auf SSH Zugang angewiesen. Alles also eine Verkomplizierung in der Handhabung. Ist das so schwer zu verstehen?

[harrym]

einstellen kannste es unter /opt/iobroker/iobroker-data. Da gibt es das File iobroker.json.

Da findest du den Punkt "log"

Hier kannst du die Tage und auch den "Warn" Level ändern.

Ich logge in dem File nur die ERROR. Den Rest sehe ich weiterhin direkt im IO unter LOGs.

[Mauflo]

@harrym sagte in Plötzlich logfiles als .gz files:

/opt/iobroker/iobroker-data

dort steht 7 Tage das weiß ich - aber das logfile des letzten Tages wird seit dem neuen js-controller automatisch gezippt! Und sowohl mit Button als auch jetzt ohne Button ist der Zugang nur mehr über SSH möglich.

[harrym]

also bei mir nicht ... ? komisch

ok. ich bin halt der typ, der sich logfiles dann mal anguggt, wenn etwas nicht funktioniert. Somit hab ich das auch nicht via GUI beobachtet.

[Mauflo]

@harrym ist ja auch ok. Aber offensichtlich sehen das hier mehrere als Rückschritt. Wenn man Dinge jahrelang gewohnt war, die einem das Leben vereinfacht haben, wird man eben sensibel, wenn es plötzlich ohne Grund verkompliziert wird! ;-)

[Mauflo]

@harrym sagte in Plötzlich logfiles als .gz files:

also bei mir nicht ... ? komisch

Kommt auch darauf an welche Versionen Du installiert hast!

[harrym]

@Mauflo ich gestehe ... hab auf dieses Feature auch nie geachtet.

[apollon77]

Hi,

viele User arbeiten mit SD Karten und damit steht Systembedingt eher eine Kleine Menge Speicherplatz zur Verfügung. Kein Vergleich zu SSDs oder HDDS. Auch hatten wir in der letzten Zeit auch Fälle wo diese (u.a. wegen zu grosser Logs und weil niemand da sonst rein schaut) Fälle wo die SD plötzlich voll war.

Aus diesem Grund und auch weil, wie schon erwähnt, es durchaus sehr gängige Praxis für Logfiles in der Linux-Welt ist habe ich dieses Feature eingebaut.

Falls es wirklich stört ist eine Option mal ein GitHub Issue anzulegen dieses Feature deaktivierbar zu machen. :-)
Und wenn es ggaaaaaaaar nicht anders geht:
Editiere die Datei /opt/iobroker/node_modules/iobroker.js-controller/lib/logger.js in Zeile 150 (bei controller 2.2.8) und schreibe dort

                    transport.zippedArchive = false;

Beim nächsten Controller update musst Du das freilich wieder neu machen.

Der Admin Support für die gepackten Logfiles wird noch kommen.

[Mauflo]

@apollon77 Im Augenblick fehlt sogar der Button. Also bringt es derzeit nichts irgendetwas einzustellen. Aber Danke für Deine Mitteilung und auch die Erklärung. Man kann die Motivation für diese Änderung jetzt zumindest etwas verstehen. Wenn der Admin Support für die gepackten Logfiles eh kommt, brauche ich wohl derzeit kein Issue anlegen. Ich habe dort zumindest hinterlegt, dass derzeit der Button fehlt. Das scheint aber durchaus Absicht gewesen zu sein, bis das Feature wieder aktualisiert wurde. Wie gesagt, jetzt kann man es verstehen und auch auf das entsprechende Update warten! Danke!

[Dr. Bakterius]

@apollon77 sagte in Plötzlich logfiles als .gz files:

viele User arbeiten mit SD Karten und damit steht Systembedingt eher eine Kleine Menge Speicherplatz zur Verfügung. Kein Vergleich zu SSDs oder HDDS

Wer arbeitet heute noch mit so "kleinen" SD-Karten? Da würde ich mir eher Gedanken darüber machen, dass die Karte wegen zu vieler Schreibzugriffe früher defekt wird. Und wenn man ein bestehendes File packt, finden automatisch Schreibzugriffe statt. Fällt vermutlich im Vergleich zu anderen Schreibaktivitäten nicht ins Gewicht, aber dass wegen sechs unkomprimierten Log-Dateien der Platz zu knapp wird wohl eher auch nicht.

Aber ich habe jetzt mal ein GitHub-Issue (https://github.com/ioBroker/ioBroker.admin/issues/501) dazu erstellt...