Mediathekview schreibt laufend in .xsession-errors
-
@kaimon sagte in Mediathekview schreibt laufend in .xsession-errors:
Ich wollte eigentlich die wunderschön ausgearbeitete ASCII Grafik von Mediathekview präsentieren, aber das hat nicht funktioniert
Und sorry, ich kann leider in diesem Forum nicht editieren.Dann klicke mal auf die drei vertikalen Punkte.
-
@kaimon sagte in Mediathekview schreibt laufend in .xsession-errors:
Achja, .xsessionrc hat nur für bash relevantes und einige bash Modifikationen und Pfadanweisungen, von denen ich nicht glaube, daß sie hier relevant sind.
/etc/X11/Xsession.options:
allow-failsafe
allow-user-resources
allow-user-xsession
use-ssh-agent
use-session-dbusIch schaue grad /etc/X11/Xsession.d/ durch aber habe nichts verdächtiges gefunden.
Es gibt auch keinerlei Option wo man einstellen könnte was ~/.xsession-errors logged und was nicht. In der Richtung brauchst du gar nicht zu suchen.
Man kann sie höchstens ganz abschalten, aber das will man am End auch nicht.
Nachvollziehen kann ich das hier auf jeden Fall nicht, MV schreibt dort nicht rein. Aber ein Spiel bei mir, wie ich gerade festgestellt habe. Auf 22M angewachsen und jeden einzelnen Spielzug protokolliert. Tolle Wurst…Im laufenden Betrieb leeren kann man die Datei übrigens mit
echo > ~/.xsession-errors -
Angeblich wird STDERR in .xsession-errors umgeleitet, ob auch STDOUT ist nicht ganz klar.
Seid Ihr sicher, daß nicht doch in MV irgendwo das debug level definiert wird?
Oder doch in meinem System? Leider hat mir Startpage überhaupt nicht weitergeholfen, es beschweren sich zwar viele Leute über “huge .xsession-errors files” (im 3stelligen GB Bereich), aber außer löschen und abschalten fällt denen auch nichts ein. -
Könnte bitte jemand, der das Problem nicht hat, mal MV anmachen und mit folgenden Befehlen prüfen, ob STDERR und STDOUT von Java nach .xsession-errors umgeleitet wird?
pgrep java
lsof -p <eben ermittelte PID von Java>Im output müßte sowas stehen:
java 4187 0r CHR 1,3 0t0 6090 /dev/null
java 4187 1w REG 8,72 11043369 2883624 ~/.xsession-errors
java 4187 2w REG 8,72 11043369 2883624 ~/.xsession-errorsDie FD 0, 1 und 2 müßten STDIN, STDOUT und STDERR sein.
-
bei mir auch nach /dev/null
java 28615 alex 0r FIFO 0,10 0t0 62976623 pipe java 28615 alex 1w CHR 1,3 0t0 6 /dev/null java 28615 alex 2w CHR 1,3 0t0 6 /dev/nullDu nutzt xfce4? vermute die haben da eine doofe Option dass vieles in diese Datei geleitet wird oder ein Bug in zusammen hang mit Java.
Ubuntu 16.04 -
@alex
Interessant ist ja daß bei dir 0 in eine Pipe geleitet wird, bei kaimon und bei mir mir nach /dev/null
Anscheinend scheint daß schon sehr vom eigenen Environment abzuhängen, was wann wer wohin schreibt.
Hier zum Beispiel nur einfacher Window Manager fluxbox, kein Desktop Environment involviert. Ich würde mich bei er Suche nach Ursache auch in diese Richtung bewegen wollen. Anderen WM ausprobieren, oder jungfräulichen User anlegen und testen ob es dann auch dorthin schreibt, Ursache einkreisen. -
Irgendwie ist dieser Post vorhin untergegangen. Könntet Ihr noch dazu vermerken, welche Distrobasis Ihr benutzt?
MV schreibt den ganzen Kram inklusive jedes einzelnen heruntergeladenen MByte in STDOUT, wie ich mit folgendem Terminal-Befehl feststellen konnte:
java -Xms128M -Xmx1G -jar /opt/mediathekview/MediathekView.jar 1>~/out.log 2>~/err.logSTDERR ist leer. Die Konfiguration meines Systems ist anscheinend so, daß STDOUT und STDERR von allem, was mit GUI läuft, nach .xsession-errors umgeleitet wird. Das scheint durchaus Standard zu sein. Ich bin gespannt, ob das bei Euren Systemen anders konfiguriert ist, bitte beantwortet meinen vorigen Post und schreibt Eure Distro dazu.
Die generelle Umleitung macht bei allen anderen Anwendungen auch keine Probleme, weil die nicht so geschwätzig sind wie MV. Die einfachste Lösung wäre, wenn man bei MV den debug level so einstellen könnte, daß STDOUT nur ein paar Zeilen über den Start enthält und danach schweigt. Vielleicht eine Startoption --nonverbose?
Ansonsten müßte ich STDOUT systemweit oder zumindest für Java nach /dev/null umleiten und ehrlich gesagt, weiß ich nicht, wie ich rausfinden soll, wie das geht. Und das wäre auch ein ziemlicher Systemeingriff, den ich gern vermeiden würde.
-
Ich habe keine anderen Java-Anwendungen und wüßte also nicht, wie ich das testen sollte. Die Umleitung von STDOUT nach .xsession-errors besteht aber generell nicht nur für Java, sondern insgesamt für den WM und alle wesentlichen XFCE-Komponenten. Auch Firefox schreibt da seine Debug-Meldungen rein, das sind allerdings nur wenige Zeilen.
Mir fiel grad ein, auf unserem Spielerechner nach Minecraft (=Java) zu schauen - ja, auch Minecraft schreibt da rein, für meinen Geschmack auch zu viel, aber doch nur gelegentlich und, wenn das Spiel erstmal läuft, überwiegend Fehler und Warnmeldungen.
MV aber schreibt im Sekundentakt und das ist das Problem. -
Dann würde ich mal beim XFCE ansetzen. Neuen User mit frischem Profil anlegen, testen ob das dann auch passiert. Verhalten unter andere Desktop-Umgebung oder nur mit einem reinen Window-Manager testen um die Ursache einzugrenzen.
Was ziemlich sicher nicht die Ursache ist, ist MV selber. -
Ich denke, die Ursache ist geklärt, da brauche ich keinen neuen user anzulegen oder Versuche mmit anderen WM anzustellen:
-
MV schreibt laufend und im Sekundentakt in STDOUT. Die Ursache dafür ist MV.
Einen sachlichen Grund für dieses Verhalten kann ich nicht erkennen. Wer benötigt im Normalbetrieb einer GUI-Anwendung ASCII-Grafiken auf STDOUT? Oder sekündliche Erfolgsmeldungen? -
XFCE leitet STDOUT nach .xsession-errors um, jedenfalls in meiner Distro. Die Ursache dafür ist die Konfiguration von XFCE. Und diese Konfiguration ist prinzipiell richtig, denn wenn man bei einer Anwendung den Debug-Modus anmacht, möchte man diese Ausgaben im Log haben, dafür ist das Log da.
-
Andere WM leiten STDOUT anscheinend nach /dev/null, um dem Problem übermäßig geschwätziger Anwendungen entgegenzuwirken. Das ist eine Krücke.
Aus meiner Sicht richtiger Ansatz, um das Problem zu lösen: MV nur noch das Nötigste mitteilen lassen.
Ehrlich, im Sekundentakt - das kann doch für niemanden sinnvoll sein. -
-
@kaimon sagte in Mediathekview schreibt laufend in .xsession-errors:
Aus meiner Sicht richtiger Ansatz, um das Problem zu lösen: MV nur noch das Nötigste mitteilen lassen.
Ehrlich, im Sekundentakt - das kann doch für niemanden sinnvoll sein.Fakt ist zum aktuellen Zeitpunkt können wir das nicht so schnell ändern.
Da MediathekView so programmiert wurde dass die Logausgaben alle selber gebaut wurden anstatt einen Logger zu nutzen kann man nicht so mal eben das umbauen.
Aber da du ein Linux nutzt kannst du eventuell die ausgaben erzwungenermaßen nach /dev/null umleiten?
alsojava -jar MediathekView.jar > /dev/null
Oder ignoriert dass dein Windowmanager und klemmt sich dazwischen?Da MediathekView irgendwann in der Zukunft größere Änderungen erfährt wird da auch in dem Zuge ein Logging mit Logger eingebaut, dann kann man das Loglevel beeinflussen.
-
@vitusson: … und tschüß.
@georg-j: super, auf so einen Vorschlag hab ich gehofft - das schaue ich mir genauer an.
@alex: Dafür hab ich volles Verständnis. Danke, daß Du planst, das Problem aufzugreifen. Und den Startparameter werde ich auch ausprobieren.
Ich bin übers WE weg, aber ich melde mich wieder mit den “Versuchsergebnissen”.
-
-
@alex: Ich muß mich korrigieren, ~/> wird als Arbeitsverzeichnis angelegt, der Rest wird ignoriert. Ich starte MV allerdings nicht aus dem Terminal, sondern mit einem Starter und da geht der Parameter offensichtlich nicht.
Den XFCE-Usern zuliebe könntet Ihr vielleicht überlegen, den von Georg genannten Parameter per default auf “false” zu setzen. Allen anderen schadet das nicht, die loggen eh nach /dev/null. Und wer debuggen will, kann das ja einfach wieder auf “true” setzen.
Oder jedenfalls einen Tipp in der Hilfe?
