Mediathekview schreibt laufend in .xsession-errors

[kaimon]

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.

[kaimon]

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-errors

Die FD 0, 1 und 2 müßten STDIN, STDOUT und STDERR sein.

[vitusson]

1 und 2 gehen bei mir auch nach /dev/null

Vielleicht solltest du mal ein anderes Java-Programm starten und checken ob das dann auch beide nach .Kanäle xsession-error umleitet

[alex]

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/null

Du 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

[vitusson]

@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.

[kaimon]

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.log

STDERR 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.

[kaimon]

Achso, und 0 ist STDIN, wieso das bei einem aus ner pipe und bei den den anderen aus /dev/null beschickt wird verstehe ich nicht so recht, aber ist in diesem Zusammenhang eher irrelevant. Aber bisher hab ich schon wieder ne Menge gelernt.

[vitusson]

Debian. Altstabil.

Die Antwort auf die Frage ob andere Java-Anwendungen auch so geschwätzig sind hast du noch nicht beantwortet.

[kaimon]

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.

[vitusson]

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.

[kaimon]

Ich denke, die Ursache ist geklärt, da brauche ich keinen neuen user anzulegen oder Versuche mmit anderen WM anzustellen:

1. 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?

2. 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.

3. 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.

[vitusson]

Okay, ich dann dann raus. Du hast offenkundig absolut kein Interesse das Problem zu analysieren, da deine Schlussfolgerung sowieso schon feststeht. Kann man machen, dann soll man sich aber nicht wundern wenn man nicht weiterkommt.

[Georg-J]

@kaimon Dann konfiguriere dir das weg: __system-parameter__dl_progress_ von true auf false in der mediathek.xml.

[alex]

@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?
also java -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.

[kaimon]

@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”.

[kaimon]

@alex: java -jar MediathekView.jar > /dev/null führt, wenn ich das richtig interpretiere, dazu, daß MV versucht /dev/null als Arbeitsverzeichnis zu benutzen. Meine Konf wird dann nicht mehr gefunden.
@Georg-J: Das scheint zu funktionieren. Super, vielen Dank!

[kaimon]

@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?