Hallo Matthias,
du kannst das mit der Begrenzung auf meinem Wolf bitte gerne einrichten.
Beste Grüße
Jens
Insider Preview IP 2 zur V 4.8 - veröffentlicht
Verehrte Nutzer des Timberwolf Servers. Wir haben die IP2 zur nächsten Hauptversion 4.8 für alle Modelle des Timberwolf Servers freigegeben.
Diese neue Version enthält tolle Erweiterungen zur Timberwolf VISU mit Jalousie Widget, neuen herbstlichen Hintergründen und freier Hintergrundangabe per RGB / CSS
Release Notes im Wiki: https://elabnet.atlassian.net/wiki/x/AQDpzg
AKTION: Bitte unterstütze uns mit einem Software-Wartungsvertrag, damit wir dieses Projekt fortführen können und damit Dein Server weiterhin Updates, Upgrades und Support erhält. Jetzt in der Aktion schenken wir Dir den Insider Club mit derselben Laufzeit wie der am längsten laufende aktive Wartungsvertrag dazu - bei sofortigem Laufzeitbeginn. Damit profitierst Du auch von einer vorzeitigen Verlängerung. Alle Infos: https://elabnet.atlassian.net/wiki/x/GQB8z
[Problem] [V1.5.3] "unable to retrieve container logs" nach Update
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
blaubaerli
- Beiträge: 2743
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 1034 Mal
- Danksagung erhalten: 836 Mal
| timberwolf168 | (2600er) | VPN offen | Reboot nach Vereinbarung |
| timberwolf1699 | (3500XL) | VPN offen | Reboot jederzeit |
| wiregate1250 |
-
blaubaerli
- Beiträge: 2743
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 1034 Mal
- Danksagung erhalten: 836 Mal
Hallo Matthias (@ms20de),
hast du hier schon etwas erreichen können?
Beste Grüße
Jens
hast du hier schon etwas erreichen können?
Beste Grüße
Jens
| timberwolf168 | (2600er) | VPN offen | Reboot nach Vereinbarung |
| timberwolf1699 | (3500XL) | VPN offen | Reboot jederzeit |
| wiregate1250 |
-
blaubaerli
- Beiträge: 2743
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 1034 Mal
- Danksagung erhalten: 836 Mal
Hallo zusammen,
nachdem das ja hier noch ein wenig in der Luft hing.....
Ich hatte mich gewundert, woher diese Unmengen an Loginfos plötzlich kommen sollten.... Da ich mir die aber auch nicht ansehen konnte, habe ich den Container dann einfach mal neu deployed. Damit ware die alten Logs zwar alle weg, aber ich hatte wieder Zugriff auf die Loganzeige und habe dann jede Menge Einträge gesehen, die nicht nativ aus meinem eigenen Plugincode geschrieben wurden.
Im Rahmen eines anderen Problems hatte ich jedoch in Zusammenspiel mit den Kollegen der EalbNET die Log- und Tracelevel in der plugins.conf umkonfiguriert. Das erzeugte dann ungewohnt viel Logoutput und produzierte schließlich hier die enormen Logmengen.
Ursprünglich dachte ich, dass man die Größe des Ringpuffers für die Loginformationen durch das Setzen des "Lines"-Parameters hier:
selbst beeinfluss kann. Aber das scheint in der Tat nur die Einstellung für den eigentlichen "Log viewer" zu sein. Ich verstehe aktuell die Ursache des Problems damit aber immer noch nicht ganz. Matthias hat im Post 10 signalisiert, dass das ein Timing Problem sei. Auf der anderen Seite sieht es auch nach einem Problem mit der Größe des tatsächlich geschriebenen Logfiles aus.
Bei den Linux-Systemen mit denen ich im Alltag zu schaffen habe, ist das mit der Anzeige der letzten n Zeilen eines Logfiles üblicherweise was für das Kommando "tail". Da habe ich aber solche massiven Performance-Differenzen auch bei extrem großen Logfiles noch nicht erlebt.
Ist das ggf. noch ein Thema der Implementierung bei portainer?
Egal wie ich den Tracelevel ja nun eingestellt habe, dann ist das ja nun nur ein Problem der Zeit bis das Log wieder soooooo voll ist und dann das Thema von vorne beginnt, oder?
Beste Grüße
Jens
nachdem das ja hier noch ein wenig in der Luft hing.....
Ich hatte mich gewundert, woher diese Unmengen an Loginfos plötzlich kommen sollten.... Da ich mir die aber auch nicht ansehen konnte, habe ich den Container dann einfach mal neu deployed. Damit ware die alten Logs zwar alle weg, aber ich hatte wieder Zugriff auf die Loganzeige und habe dann jede Menge Einträge gesehen, die nicht nativ aus meinem eigenen Plugincode geschrieben wurden.
Im Rahmen eines anderen Problems hatte ich jedoch in Zusammenspiel mit den Kollegen der EalbNET die Log- und Tracelevel in der plugins.conf umkonfiguriert. Das erzeugte dann ungewohnt viel Logoutput und produzierte schließlich hier die enormen Logmengen.
Ursprünglich dachte ich, dass man die Größe des Ringpuffers für die Loginformationen durch das Setzen des "Lines"-Parameters hier:
selbst beeinfluss kann. Aber das scheint in der Tat nur die Einstellung für den eigentlichen "Log viewer" zu sein. Ich verstehe aktuell die Ursache des Problems damit aber immer noch nicht ganz. Matthias hat im Post 10 signalisiert, dass das ein Timing Problem sei. Auf der anderen Seite sieht es auch nach einem Problem mit der Größe des tatsächlich geschriebenen Logfiles aus.
Bei den Linux-Systemen mit denen ich im Alltag zu schaffen habe, ist das mit der Anzeige der letzten n Zeilen eines Logfiles üblicherweise was für das Kommando "tail". Da habe ich aber solche massiven Performance-Differenzen auch bei extrem großen Logfiles noch nicht erlebt.
Ist das ggf. noch ein Thema der Implementierung bei portainer?
Egal wie ich den Tracelevel ja nun eingestellt habe, dann ist das ja nun nur ein Problem der Zeit bis das Log wieder soooooo voll ist und dann das Thema von vorne beginnt, oder?
Beste Grüße
Jens
| timberwolf168 | (2600er) | VPN offen | Reboot nach Vereinbarung |
| timberwolf1699 | (3500XL) | VPN offen | Reboot jederzeit |
| wiregate1250 |