Gelöst: Logging von yaVDR in separaten Logfiles anstelle des syslog und Probleme durch initctl

  • Hallo Leute,
    in einem gesunden Linux system sollten der syslog eigentlich nur zentrale Informationen enthalten, und nach Möglichkeit nicht mit Anwendungsinformationen überschüttet werden. Ich schaue zum Beispiel als erstes mitail -f /var/log/syslog auf den Zustand eines Systems und erwarte nur wenige Zeilen zu sehen. Werden in jeder Sekunde Hundertee ausgeworfen, benötigt man eben Tools um dieses zu Filtern.
    Beim yavdr 0.4 Standardsetup ist das oft nicht der Fall, zu viele Informationen insbesondere von vdr Komponenten machen die Nutzung etwas schwer. Insbesondere XVDR ist geschwätzig schreibt viele Informationen, zum Beispiel beim EInlesen von Hunderten von VDR Aufnahmen von verschiedenen Geräten einen Sturm von Mitteilungen, daß die Aufnahmen sich geändert haben (und ich weiß noch nicht, ob man das ohne Code Änderungen bändigen kann)


    Um das ganze mal systematisch anzugehnd zu bändigen habe ich angefangen die VDR Moittzu separieren. Der vdr selbst hat ja die Möglichkeit, via -l oder --log= die syslog seperat zu halten. Ich habe daher mal versucht, das setup meines 1.6 basierten VDR auf yavdr zu übertragen, habe aber da ein paar Probleme. Ich bin noch am analysieren, wie der Startvorgang genau läuft, könnte daher Hilfestellung von den "Wissenden" oder den Implementierern gebrauchen.


    Ein erster Schritt, der vielleicht auch zukünftig in den Standard übernommen werden könnte, würde in einem eigen LOGUSER Kanal bestehen. Dazu müsste nur eine Datei z.B. /etc/rsyslog.d/30-vdr.conf mit Inhalt

    Code
    1. #/etc/rsyslog.d/30-vdr.conf
    2. # vdr messages to vdr.log
    3. local6.* -/var/log/vdr/vdr.log


    angelegt werden und mit reload rsylogd der syslog daemon neu gestartet werden. Dann würde automatisch alles, was an log Kanal 6 geschrieben würde, aus dem syslog stream entfernt und in die /var/log/vdr/vdr.log geschrieben werden. Eigentlich ist dafür die vdr option -l oder --log= zuständig und theoretisch sollte als z.B. eine Erweiterung des OPTIONS Eintrages in /etc/default/vdr ausreichen:

    Code
    1. OPTIONS="-w 0 --logs=2.6"


    Die erste Zahl vor dem "." ist der Level, die zweite nach dem Punkt der Kanal
    Leider führt das - vermutlich wegen vom mit dem Upstart Skript aufgerufenen Funktionen - beim yaVDR 04 zu einer effektiven Kommandozeile

    Code
    1. /usr/bin/vdr --log=2 6 --lirc=/var/run/lirc/lircd -v ...

    , d.h. der Punkt wurde - wahrscheinlich durch ein SED Skript beim Aufbauen der Commandline - entfernt. Und das bedeutet, daß nur der Log-Level spezifiziert wird.
    Ich habe versucht, dem /etc/init/vdr.conf zu folgen und vermutete, daß letztlich die letzte Zeile den vdr startet.
    Daher habe ich probeweise die auf

    Code
    1. exec $DAEMON --log=2.6 --lirc=$LIRC -v $VIDEO_DIR -c $CFG_DIR -L $PLUGIN_DIR -r $REC_CMD -s $VDRSHUTDOWN -E $EPG_FILE -u $USER -g /tmp --port $SVDRP_PORT $OPTIONS "${PLUGINS[@]}" $REDIRECT &> /tmp/vdr.log
    2. end script

    , aber auch dort wurde der Punkt gefressen, egal of ich den mit --log="2.6" oder --log=2\.6 zu schützen versuche.
    In ps und in cat /proc/<pid_of_vdr/cmdline| tr "\0" "\n" sieht man die Verfälschung der log option.


    Das exec ist es nicht, denn ein exec vi -- --log=2.6 führt zum editieren einer Datei namens "--log=2.6", d.h. exec filtert nicht.
    Bleibt nur der initctl Mechanismus (restart ist z:b: nur ein Symlink auf initctl). Hat jemand eine Idee wie das zu bändigen ist?


    VDR Zooverwalter


    • 1x Ubuntu 12.10 MCP78S [Geforce 8200] Vdr 1.7.22 / 2x Hauppauge WINTV NOVA-T 500 TV Karte PCI intern (=4 DVB-T)

    • 1x Ubuntu 13.04 1xVDR 1.7.28 mit vnsi / DVB-S2 Hauppauge Nova /L4M Twin S2 V 6.2, Unicable

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2, USB TechnoTrend S2-3650 mit CI, HDMI an Philips LCD 47PFL8404 Full HD

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2,Streamdev-client HDMI an Samsung LED 5700-46"

    • 1x yaVDR0.5 testing Asus Eeepc Notebook DVB-S USB TechnoTrend S-2400 HDMI an Samsung LED 5700-40"

    • 1x yavdr05-clone (32bit) Asus Novalite, nur StreamdevClient an No-name TV mit DVI/HDMI

    • [1x yaVDR0.4 MSI MS-7508 K9N2GM, AMD Athlon Dual Core 4850e, Terratec Synergy S2 PCI HD, ALBA TV mit HDMI als Monitor
      sowie weitere Clients

    • XBMC 12.2 via VNSI

    • BoxeeBox

    • AppleTV 2nd (2.2.1 mit Jailbreak und XBMC)

    • miniMac 10.6.6 mit XBMC


    The post was edited 1 time, last by einnordlicht: Änderung des Titelthemas auf Gelöst ().

  • Anmerkung am Rande: Warum kommen eigentlich so manche gute Vorschläge von kompetenten Leuten erst, nachdem man die finale Version 0.4 veröffentlich hat und nicht in den vier Monaten davor, in denen man zwei pre-Versionen für interessierte Tester angeboten hat? :D Das hier ist keine Kritik, sondern verstecktes Lob! :D


    Gruß
    hepi

  • Erstmal nur kurz überflogen. Nach deiner Beschreibung klingt es nach einem Bug im VDR (kann das sein ? ) Das exec im upstart skript ist das exec der bash , da alles zwischen script und end script von der bash ausgeführt wird. Da es mit vi funktioniert - ist eigentlich schon bewiesen das es im vdr zu suchen wäre IMHO.


    Das ist by the way etwas was ich gerne übernehmen werde beizeiten ...

  • Moin!


    So, wie ich das sehe, ersetzt der vdr den Punkt durch ein Null-Byte, um auf beide Teile atoi loslassen zu können. Das verändert die Anzeige der Kommandozeile in ps. Ist nicht wirklich ein Bug, aber eventuell überraschend.
    Oben hast du mal "--logs" und mal "--log" stehen, ich gehe mal davon aus, dass du das richtige "--log" benutzt hast...?


    Lars.


  • So, wie ich das sehe, ersetzt der vdr den Punkt durch ein Null-Byte, um auf beide Teile atoi loslassen zu können. Das verändert die Anzeige der Kommandozeile in ps. Ist nicht wirklich ein Bug, aber eventuell überraschend.


    Das ist nicht ganz richtig: Man kann für jeden Prozess mittels cat /proc/.../cmdline die resultierende Kommandozeile des Prozesses holen, wie der Prozess sie selbst sieht. C-Style, argv Array, d.h es handelt sich um eine die normale \0 Liste der Kommandozeilenargumente. Das nachfolgende tr ersetzt die Nullbytes durch linefeeds und macht die Liste einfacher lesbar: die Kommandozeilen optionen bekommt man so zeilenweise, genauso wie der vdr Prozess sie letztlich zu sehen und zu interpretieren bekommt. Demnach bekommt vdr nur --log=2 zu sehen und dann ein (zu verwerfendes) Argument 6. Das ganze findet also noch VOR vdr statt


    Ich habe mich mal mit upstart beschäftigt und bin da etwas verwirrt. Laut Ubuntu Dokumentation gilt

    Code
    1. exec and script
    2. All job files must have either an exec or script stanza. This specifies what will be run for the job.
    3. exec gives the path to a binary on the filesystem and optional arguments to pass to it; any special characters (e.g. quotes or ‘$’) will result in the command being passed to a shell for interpretation instead.


    Im /etc/init/vdr.conf haben wir aber beides, ein script... end script mit exec. Ob beides zulässig ist, kann ich noch nicht beurteilen, aber es scheint ja zu gehen.
    Ich wollte die Kommando kurz wegschreiben und händisch testen, aber leider gehen dabei die " zum Klammern der -P optinen verloren. Ich vermute, händisch wird es gehen (so ein Problem hatte ich bei 1.6 mit runvdr auch schon). Ich muß mich wohl noch einmal mit der Shell interpretation von "${PLUGINS[@]}" in /etc/init/vdr.conf beschäftigen. Seit Programmierung in Groovy und Java ist mein "shell"isch etwas eingerostet.



    Oben hast du mal "--logs" und mal "--log" stehen, ich gehe mal davon aus, dass du das richtige "--log" benutzt hast...?


    Ja, ganz normaler Typo (ich dachte, das gehört zum guten Stil hier :D )




    Anmerkung am Rande: Warum kommen eigentlich so manche gute Vorschläge von kompetenten Leuten erst, nachdem man die finale Version 0.4 veröffentlich hat und nicht in den vier Monaten davor, in denen man zwei pre-Versionen für interessierte Tester angeboten hat? :D Das hier ist keine Kritik, sondern verstecktes Lob! :D

    :O Nun ja, es lag daran, daß ich nach erscheinen der pre1 (irrtümlich) dachte, daß die Atom Prozessoren in meine Revo's gar nicht 64bittig wären, und ich so die 0.4pre ersteinmal ignoriert habe. Und dann bin ich beruflich für über 6 Wochen in einem PoC mit einem chinesischen Problemkunden untergegangen, so daß ich bei fast 100 Wochenstuden keine Zeit zu testen fand.


    Andererseits: es muß ja auch noch einen Grund für eine 0.41 geben :-) :mua


    VDR Zooverwalter


    • 1x Ubuntu 12.10 MCP78S [Geforce 8200] Vdr 1.7.22 / 2x Hauppauge WINTV NOVA-T 500 TV Karte PCI intern (=4 DVB-T)

    • 1x Ubuntu 13.04 1xVDR 1.7.28 mit vnsi / DVB-S2 Hauppauge Nova /L4M Twin S2 V 6.2, Unicable

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2, USB TechnoTrend S2-3650 mit CI, HDMI an Philips LCD 47PFL8404 Full HD

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2,Streamdev-client HDMI an Samsung LED 5700-46"

    • 1x yaVDR0.5 testing Asus Eeepc Notebook DVB-S USB TechnoTrend S-2400 HDMI an Samsung LED 5700-40"

    • 1x yavdr05-clone (32bit) Asus Novalite, nur StreamdevClient an No-name TV mit DVI/HDMI

    • [1x yaVDR0.4 MSI MS-7508 K9N2GM, AMD Athlon Dual Core 4850e, Terratec Synergy S2 PCI HD, ALBA TV mit HDMI als Monitor
      sowie weitere Clients

    • XBMC 12.2 via VNSI

    • BoxeeBox

    • AppleTV 2nd (2.2.1 mit Jailbreak und XBMC)

    • miniMac 10.6.6 mit XBMC



  • Das ist nicht ganz richtig: Man kann für jeden Prozess mittels cat /proc/.../cmdline die resultierende Kommandozeile des Prozesses holen, wie der Prozess sie selbst sieht. C-Style, argv Array, d.h es handelt sich um eine die normale \0 Liste der Kommandozeilenargumente. Das nachfolgende tr ersetzt die Nullbytes durch linefeeds und macht die Liste einfacher lesbar: die Kommandozeilen optionen bekommt man so zeilenweise, genauso wie der vdr Prozess sie letztlich zu sehen und zu interpretieren bekommt. Demnach bekommt vdr nur --log=2 zu sehen und dann ein (zu verwerfendes) Argument 6. Das ganze findet also noch VOR vdr statt


    Und schon muss ich Abbitte tun: Ich habe die Kommandozeile händisch gestartet (ohne upstart) und des Effekt ist exakt der gleiche. Inzwischen habe ich mir auch die vdr Sourcen geholt and in vdr.c nachgeschaut (hätte ich besser gleich gemacht). In der Tat hat mini73 Recht: vdr ersetzt den . durch \0 zum Parsen der beiden Logbestandteile und das Resultat ist in /proc zu sehen. (Mach auch Sinn, denn das /proc Filesystem wurde eingeführt, um die Kontextinformationen File-like anzubieten).


    Leider kann ich nicht sehen, ob das Setzen von LOG_LOCAL6 erfolgt, da vdr keinen SyslogEIntrag darüber erzeugt. Auf jeden Fall ziehen die Settings scheinbar nicht, die bei meinem Alt-System mit VDR 1.6 noch funktionierten.


    Entscheident ist für das Öffnen des Syslog (mittels openlog in line 512 in vdr.c) das gewählte SysLogTarget, was aus dem 2.Wert von logs=Level.Target (Target [0..7]) anscheinend sauber übergeben wird. Und danach sollte alles so funktionieren


    VDR Zooverwalter


    • 1x Ubuntu 12.10 MCP78S [Geforce 8200] Vdr 1.7.22 / 2x Hauppauge WINTV NOVA-T 500 TV Karte PCI intern (=4 DVB-T)

    • 1x Ubuntu 13.04 1xVDR 1.7.28 mit vnsi / DVB-S2 Hauppauge Nova /L4M Twin S2 V 6.2, Unicable

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2, USB TechnoTrend S2-3650 mit CI, HDMI an Philips LCD 47PFL8404 Full HD

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2,Streamdev-client HDMI an Samsung LED 5700-46"

    • 1x yaVDR0.5 testing Asus Eeepc Notebook DVB-S USB TechnoTrend S-2400 HDMI an Samsung LED 5700-40"

    • 1x yavdr05-clone (32bit) Asus Novalite, nur StreamdevClient an No-name TV mit DVI/HDMI

    • [1x yaVDR0.4 MSI MS-7508 K9N2GM, AMD Athlon Dual Core 4850e, Terratec Synergy S2 PCI HD, ALBA TV mit HDMI als Monitor
      sowie weitere Clients

    • XBMC 12.2 via VNSI

    • BoxeeBox

    • AppleTV 2nd (2.2.1 mit Jailbreak und XBMC)

    • miniMac 10.6.6 mit XBMC


    The post was edited 3 times, last by einnordlicht: Erweiterung (neue Erkenntnisse), Typo: LAt System-> Alt System ().

  • Tja, und wieder ein Schrittchen weiter: die Angabe des Channel ist gegenüber meinem anderen System entweder Case sensitiv geworden oder war es immer und die Schreibweise hat sich geändert.
    Wenn man in /etc/rsyslog.d/30-vdr.conf

    Code
    1. # vdr messages to vdr.log
    2. LOCAL6.* -/var/log/vdr/vdr.log

    einträgt, landen die VDR spezifischen Einträge in /var/log/vdr/vdr.log. Leider scheint das - aber nicht zu ziehen, weil die Logeinträger derzeit bei mir immer noch im normalen SYSLOG zusätzlich landen. Immerhin ein erster Schritt...
    Übrigens müßte bei einer Verschiebung der vdr Log-Einträge ggf die WebConsole angepasst werden, um auch dort die vdr spezifischen Log sehen zu können.


    VDR Zooverwalter


    • 1x Ubuntu 12.10 MCP78S [Geforce 8200] Vdr 1.7.22 / 2x Hauppauge WINTV NOVA-T 500 TV Karte PCI intern (=4 DVB-T)

    • 1x Ubuntu 13.04 1xVDR 1.7.28 mit vnsi / DVB-S2 Hauppauge Nova /L4M Twin S2 V 6.2, Unicable

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2, USB TechnoTrend S2-3650 mit CI, HDMI an Philips LCD 47PFL8404 Full HD

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2,Streamdev-client HDMI an Samsung LED 5700-46"

    • 1x yaVDR0.5 testing Asus Eeepc Notebook DVB-S USB TechnoTrend S-2400 HDMI an Samsung LED 5700-40"

    • 1x yavdr05-clone (32bit) Asus Novalite, nur StreamdevClient an No-name TV mit DVI/HDMI

    • [1x yaVDR0.4 MSI MS-7508 K9N2GM, AMD Athlon Dual Core 4850e, Terratec Synergy S2 PCI HD, ALBA TV mit HDMI als Monitor
      sowie weitere Clients

    • XBMC 12.2 via VNSI

    • BoxeeBox

    • AppleTV 2nd (2.2.1 mit Jailbreak und XBMC)

    • miniMac 10.6.6 mit XBMC


  • So tuts das bei mir (letzte Zeile verwirft das denn für die folgenenden Logs):
    ---
    local0.* /var/log/vdr/vdr.log
    local0.* /dev/tty11


    local0.* ~
    ---


    Geht aber auch noch feiner
    ---
    if $syslogfacility-text == 'local0' and $msg contains 'changing pids of channel ' then ~


    if $syslogfacility-text == 'local0' and $msg contains 'frontend 0 timed out while tuning to channel 0,' then ~
    if $syslogfacility-text == 'local0' and $msg contains 'frontend 1 timed out while tuning to channel 0,' then ~
    ---
    wenn man Loglevel 2 haben will aber den Standartkram nicht sehen braucht.



    Aber konkret hängt im Detail wohl auch vieles von der eingesetzten syslog Version ab.



    cu

  • Es geht auch mit local6, wenn man dann den Inhalt nicht im syslog will sollte man nach meinem Verständnis das auch sagen:


    # vdr messages to vdr.log and only there
    local6.* -/var/log/vdr/vdr.log
    local6.* ~


    Ich habe mir mal die Mühe gemacht und das im debugger durchgesteppt - da läuft es richtig.


    /usr/bin/vdr-dbg --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s /usr/lib/vdr/vdr-shutdown.wrapper -E /var/cache/vdr/epg.data -u vdr -g /tmp --port 6419 -w 0 --log 2 6


    Irgendwie dachte ich am Anfang es geht nicht, - Jetzt krieg ich es grad nicht kaputt ...


  • Danke Leute.
    War gestern abend schon etwas spät und ich hatte die Bedeutung der Prefix Operator - und ~ verwechselt. - sagt nur, daß nicht nach jeder Zeile gesynct werden soll, ~ wirft die Zeile weg.
    Ja, und ist es nicht Wahnsinn: Kaum macht man es richtig, funktionierts....


    Mit den Filtern werde ich jetzt mal den Tonnen von sinnfreien Mitteilungen à la

    zu Leibe rücken.


    Vielleicht lohnt es sich ja auch, Plugin spezifische Mitteilungen seperat in /var/log/vdr/vdr.pluginname.log auszuleiten.


    VDR Zooverwalter


    • 1x Ubuntu 12.10 MCP78S [Geforce 8200] Vdr 1.7.22 / 2x Hauppauge WINTV NOVA-T 500 TV Karte PCI intern (=4 DVB-T)

    • 1x Ubuntu 13.04 1xVDR 1.7.28 mit vnsi / DVB-S2 Hauppauge Nova /L4M Twin S2 V 6.2, Unicable

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2, USB TechnoTrend S2-3650 mit CI, HDMI an Philips LCD 47PFL8404 Full HD

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2,Streamdev-client HDMI an Samsung LED 5700-46"

    • 1x yaVDR0.5 testing Asus Eeepc Notebook DVB-S USB TechnoTrend S-2400 HDMI an Samsung LED 5700-40"

    • 1x yavdr05-clone (32bit) Asus Novalite, nur StreamdevClient an No-name TV mit DVI/HDMI

    • [1x yaVDR0.4 MSI MS-7508 K9N2GM, AMD Athlon Dual Core 4850e, Terratec Synergy S2 PCI HD, ALBA TV mit HDMI als Monitor
      sowie weitere Clients

    • XBMC 12.2 via VNSI

    • BoxeeBox

    • AppleTV 2nd (2.2.1 mit Jailbreak und XBMC)

    • miniMac 10.6.6 mit XBMC



  • Super, klappt. Mit meinem /etc/rsyslog.d/30-vdr.conf

    Code
    1. # vdr messages to vdr.log
    2. if $syslogfacility-text == 'local6' and $msg contains 'Recordings state changed ' then ~
    3. if $syslogfacility-text == 'local6' and $msg contains 'Requesting clients to reload recordings list' then ~
    4. local6.* -/var/log/vdr/vdr.log
    5. local6.*

    kommen auch im log level 3 die vdr spezifischen Mitteilungen ohne die enervierenden XDEV Statii in vdr.log an.
    Den Loglevel setze ich übrigens jetzt im /etc/default/vdr über

    Code
    1. # Options that will be passed to vdr's commandline
    2. # for example: OPTIONS="-w 15"
    3. OPTIONS="--log=2.6 -w 0"


    Wäre super, wenn das Abtrennen des Logs in den Standard mit aufgenommen würde, damit der syslog für wirklich zentrale Mitteilungen wie Geräteänderungen reserviert bleibt.


    VDR Zooverwalter


    • 1x Ubuntu 12.10 MCP78S [Geforce 8200] Vdr 1.7.22 / 2x Hauppauge WINTV NOVA-T 500 TV Karte PCI intern (=4 DVB-T)

    • 1x Ubuntu 13.04 1xVDR 1.7.28 mit vnsi / DVB-S2 Hauppauge Nova /L4M Twin S2 V 6.2, Unicable

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2, USB TechnoTrend S2-3650 mit CI, HDMI an Philips LCD 47PFL8404 Full HD

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2,Streamdev-client HDMI an Samsung LED 5700-46"

    • 1x yaVDR0.5 testing Asus Eeepc Notebook DVB-S USB TechnoTrend S-2400 HDMI an Samsung LED 5700-40"

    • 1x yavdr05-clone (32bit) Asus Novalite, nur StreamdevClient an No-name TV mit DVI/HDMI

    • [1x yaVDR0.4 MSI MS-7508 K9N2GM, AMD Athlon Dual Core 4850e, Terratec Synergy S2 PCI HD, ALBA TV mit HDMI als Monitor
      sowie weitere Clients

    • XBMC 12.2 via VNSI

    • BoxeeBox

    • AppleTV 2nd (2.2.1 mit Jailbreak und XBMC)

    • miniMac 10.6.6 mit XBMC


  • Vielleicht lohnt es sich ja auch, Plugin spezifische Mitteilungen seperat in /var/log/vdr/vdr.pluginname.log auszuleiten.


    Wäre super, wenn das Abtrennen des Logs in den Standard mit aufgenommen würde, damit der syslog für wirklich zentrale Mitteilungen wie Geräteänderungen reserviert bleibt.


    Also ich finde das ja stark, diese Passion sich hier so einzubringen, um den VDR auf DataCenter taugliche SLA Levels zu bekommen, und das meine ich aufrichtig.


    Aber Leute, der VDR ist ein Videorecorder, ein Spaßgerät, wenn der nicht tut, so what? Wenn Ihr Euren Lebensabschnittsgefährtinnen/-en oder Familien einen monatlichen SLA Report über den VDR abliefern müsst, ist das ein Problem das anderweitig gelöst werden müsste ... just my 2 cents.


    Regards
    fnu

    HowTo: APT pinning

  • Ich denke, wir haben in der Praxis zwei Probleme zu lösen:
    1) Die Suche nach Problemursachen in den Logfiles soll erleichtert werden. Dabei mögen Loglevel helfen, die Datenmenge zu verringern, eine Aufsplittung in viele kleine Dateien mag aber auch die Suche erschweren, es kommt auf die Präsentationsmöglichkeiten an.
    2) Auf der anderen Seite haben viele Neueinsteiger das Problem, dass sie noch nicht einmal das syslog selbst finden würden, wenn sie es suchen müssten. Und im syslog nicht erkennen, welche Zeilen für ihr Problem wichtig sind. Für diesen Teil der Nutzer sind Loglevel und Aufsplittung von Logfiles völlig egal, weil sie sich auch in nur einer Logdatei nicht orientieren können. (Ich meine das nicht abwertend: Wer als Windows-User ein VDR-System zum ersten Mal aufsetzt, lernt sowas erst langsam in den ersten zwei Jahren VDR-Betrieb.)


    Gruß
    hepi

  • Wobei sich hier wohl die wenigsten 30 Meter Logfiles über 40 Startversuche ansehen mögen.


    Ich persönlich finde es noch wichtig das nach jedem VDR Lauf das VDR Logfile rotiert wird, so hat man wirklich alles VDR Relevante in einen Logfile und muss nicht lange suchen. Das VDR Startscript darf dabei gerne noch die komplette VDR Kommandline an den Anfang und den Exitcode ans Ende schreiben.


    cu

  • VDR Log seperat möchte ich auch haben, bisher nur nie drum gekümmert. Weiteres aufsplitten : Nöö. Nächste Fingerübung wäre die fprintf's und printf's aus dem VDR zu verbannen .. Und patches an die Plugins anzubieten um "nonsense" meldungen auf den richtigen loglevel zu tun.


    Das Wegfiltern von nonsense Meldungen kann ja jeder als Fingerübung nach gusto machen.

  • Nächste Fingerübung wäre die fprintf's und printf's aus dem VDR zu verbannen .. Und patches an die Plugins anzubieten um "nonsense" meldungen auf den richtigen loglevel zu tun.


    Ohja, das nervt auch. Genaus wie das einige Plugins unbedingt ihr eigenes Loggin in ne Datei einbasteln müssen. Aber dann gibts ja noch das stdout der vom VDR gestarteten Scripte...


    Wobei ich im Moment den VDR so gepatcht habe das stdout/sdterr in Dateien gehen (Umleiten in Datei beim sTart ging irgendwie nicht), da bekommt man manchmal auch wichtige Sachen zu sehen.


    Und patches an die Plugins anzubieten um "nonsense" meldungen auf den richtigen loglevel zu tun.


    Jup, femon gab mir z.B. sekündlich ein "ERROR (femontools.c,175): Die angeforderte Funktion ist nicht implementiert" (weil der Treiber keine UNC Ausgeben kann), da werden die Logs ganz schnell ganz riesig.


    cu

  • Moin!


    Und schon muss ich Abbitte tun: Ich habe die Kommandozeile händisch gestartet (ohne upstart) und des Effekt ist exakt der gleiche.


    Kein Problem, ich hab das auch erst gestern gelernt... :-)
    Und jetzt weiß ich mehr über das Syslog, danke dir dafür!


    Lars.

  • Nächste Fingerübung wäre die fprintf's und printf's aus dem VDR zu verbannen .. Und patches an die Plugins anzubieten um "nonsense" meldungen auf den richtigen loglevel zu tun.


    Das müßte sich theoretisch recht einfach erledigen lassen, denn in vdr tools.c und tools.h ist alles enthalten.
    Die Macros aus tools.h wie esyslog() usw können dank Verwendung von stdarg Macro mit Variablen Argumenten (wie (f)printf selbst umgehen). Beispiel is in tools.c die Funktion syslog_... Theoretisch (ich nu wieder, der schon seit Jahren nicht mehr hardcore c programmiert hat und indie Sphären der Hochsprachen wie Groovy verzogen hat) liesse sich damit mit einem weiteren Macro auch die Nutzung von fprintf oder printf in esyslog oder isyslog umbiegen.
    Und das sollte auch innerhalb der Plugins funktionieren....


    VDR Zooverwalter


    • 1x Ubuntu 12.10 MCP78S [Geforce 8200] Vdr 1.7.22 / 2x Hauppauge WINTV NOVA-T 500 TV Karte PCI intern (=4 DVB-T)

    • 1x Ubuntu 13.04 1xVDR 1.7.28 mit vnsi / DVB-S2 Hauppauge Nova /L4M Twin S2 V 6.2, Unicable

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2, USB TechnoTrend S2-3650 mit CI, HDMI an Philips LCD 47PFL8404 Full HD

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2,Streamdev-client HDMI an Samsung LED 5700-46"

    • 1x yaVDR0.5 testing Asus Eeepc Notebook DVB-S USB TechnoTrend S-2400 HDMI an Samsung LED 5700-40"

    • 1x yavdr05-clone (32bit) Asus Novalite, nur StreamdevClient an No-name TV mit DVI/HDMI

    • [1x yaVDR0.4 MSI MS-7508 K9N2GM, AMD Athlon Dual Core 4850e, Terratec Synergy S2 PCI HD, ALBA TV mit HDMI als Monitor
      sowie weitere Clients

    • XBMC 12.2 via VNSI

    • BoxeeBox

    • AppleTV 2nd (2.2.1 mit Jailbreak und XBMC)

    • miniMac 10.6.6 mit XBMC


  • Ich persönlich finde es noch wichtig das nach jedem VDR Lauf das VDR Logfile rotiert wird, so hat man wirklich alles VDR Relevante in einen Logfile und muss nicht lange suchen. Das VDR Startscript darf dabei gerne noch die komplette VDR Kommandline an den Anfang und den Exitcode ans Ende schreiben.


    Das ist das nächste auf der Liste. Die VDR Kommandoline habe ich derzeit einfach und pragmatisch bisher nach /tmp/vdr.cmdline via Modifikation des /etc/init/vdr.conf geschrieben:


    Und mittels dieses Tips läßt sich das Upstart-Skript mit logger Aufruf ergänzen und die Info parallel im syslog tracen. Das kann ich ja für meine Zoo-Familienmitglieder machen, aber wie geht es dann weiter?/tmp/vdr.cmdline


    VDR Zooverwalter


    • 1x Ubuntu 12.10 MCP78S [Geforce 8200] Vdr 1.7.22 / 2x Hauppauge WINTV NOVA-T 500 TV Karte PCI intern (=4 DVB-T)

    • 1x Ubuntu 13.04 1xVDR 1.7.28 mit vnsi / DVB-S2 Hauppauge Nova /L4M Twin S2 V 6.2, Unicable

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2, USB TechnoTrend S2-3650 mit CI, HDMI an Philips LCD 47PFL8404 Full HD

    • 1x yaVDR0.5 testing Acer Revo 3610 DVB-S2,Streamdev-client HDMI an Samsung LED 5700-46"

    • 1x yaVDR0.5 testing Asus Eeepc Notebook DVB-S USB TechnoTrend S-2400 HDMI an Samsung LED 5700-40"

    • 1x yavdr05-clone (32bit) Asus Novalite, nur StreamdevClient an No-name TV mit DVI/HDMI

    • [1x yaVDR0.4 MSI MS-7508 K9N2GM, AMD Athlon Dual Core 4850e, Terratec Synergy S2 PCI HD, ALBA TV mit HDMI als Monitor
      sowie weitere Clients

    • XBMC 12.2 via VNSI

    • BoxeeBox

    • AppleTV 2nd (2.2.1 mit Jailbreak und XBMC)

    • miniMac 10.6.6 mit XBMC


  • Um das Syslog sauber zu halten, fehlt hier noch ein wichtiger Aspekt: Der Auto-Shutdown des VDR-Rechners mit speziell den Meldungen, dass eben dieser Shutdown deaktiviert ist und nicht durchgeführt wird.


    Gerade auf einem Server (den man aufgrund der Server-Eigenschaft nicht herunterfährt) ist das ein Umstand, der ein ansonsten sauberes Syslog im Abstand von ca. 10 Minuten vollknallt.


    Ergänzend zum Vorschlag von oben ergibt sich dann folgende Config-Datei für den rsyslog-Deamon:


    Code
    1. # VDR
    2. local6.* -/var/log/vdr/vdr.log
    3. local6.* ~
    4. # VDR-Shutdown-Routinen
    5. :syslogtag, startswith, "vdr-shutdown" /var/log/vdr/vdr.log
    6. & ~


    Das wäre Mal ein Anfang ...


    Damit sind es dann nur noch einzelne wenige Meldungen, die sich dennoch ins normale Syslog verlaufen.


    Bei einem aktuellen yaVDR zB

    Code
    1. Jan 23 17:14:18 microserver vdr: [18891] cTimeMs: using monotonic clock (resolution is 1 ns)
    2. Jan 23 17:14:18 microserver vdr: [18891] [general.debug] using new 1.7.11+ capture code


    Besser geeignet für eine saubere Behandlung der VDR-Logs scheint mir daher ein Abstellen auf den Syslog-Tag beginnend mit "vdr" zu sein.
    Zugleich würde man sich damit auch die Umleitung der (leider nur meisten) VDR-Meldungen nach localX über die Einstellung in der /etc/default/vdr ersparen, was die Sache gleich nochmal schöner macht (die Log-Umleitung ist nur mehr an einer zentralen Stelle im System konfiguriert --> rsyslog)


    Nachdenken könnte man auch darüber, regelmäßige sinnlose Meldugen wie "Shutdown verhindert da Konfig-mäßig deaktiviert" (sinngemäß) inkl. der dazugehörigen Meldung vom VDR-Prozess selbst überhaupt zu unterdrücken. Ehrlich gesagt ist es mir bei diesen Meldungen zu schade um die Abnutzung der Speicherzellen meiner Server-SSD.


    Vielleicht poste ich hier noch eine rsyslog-Config-Datei, die alle diese Überlegungen beinhaltet.