Posts by loswillios

    Ein Shellscript hat man immer, ob nun /usr/local/bin/runvdr oder /etc/inti.d/vdr.

    Nein, mit systemd und einer .service Datei hat man kein Shellscript mehr.

    Und für nen praxistauglichen Betrieb braucht der VDR ne Menge Sanity Checks, mit nem einfachen Starten des VDR mit psssenden Parametern ist es nicht getan.

    Das war bei mir noch nie nötig. Was prüfst du denn ab?

    Zumindest muss man den Exit Code prüfen und entsprechend handeln, ferner brauchts nen harten Kill nach nem (längeren) Timeout. Ohne das kann man den VDR IMHO nicht alleine lassen.

    Die Exitcodes werden von systemd abgefangen und behandelt. Und falls man einen längeren Timeout benötigt kann man den Parameter "RestartSec=" einsetzen, siehe http://0pointer.de/public/systemd-man/systemd.service.html

    Also mit der Variante aus dem ersten Post würde ich den VDR nicht alleine lassen wollen Im Zweifel verbringt er dann die zwei Wochen Urlaub mit nem Dauerneustart

    Das kann dir mit einem Shellscript ebenso passieren. Und der Dauerneustart wird AFAIK von systemd abgefangen und der service dann in den Zustand "failed" versetzt.

    Wenn man von unseren upstart Erfahrungen ausgeht - sollte vdr und das frontend definitiv 2 seperate Dienste sein. - Aber sicher Geschmackssache - so wie mir scheint sind das ja eher vdr.service files für die ganz persönliche Installation. Ein Großteil der Logik aus unserem upstart Job dürfte dementsprechend in der runvdr liegen.

    Sobald du mittels Skripten deine Kommandozeilenparameter zusammenflickst wird das ganze doch sehr anfällig? Das ist leider der Nachteil am VDR, sehr viel wird über Parameter gelöst.


    Was mir auffällt: Heißt der Dienst lirc oder lircd ? Gibt es einen eine Abstraktion für "das was /var/run/lirc/lircd oder /run/lirc/lircd zur Verfügung stellt" ? Was ist mit Netzwerk, alsa etc pp ?

    Hier heißt der Dienst lircd, also lircd.service. Netzwerk, Sound, etc werden von anderen .service Dateien zur Verfügung gestellt, z.B. NetworkManager.service, alsa-[store,restore].service

    Meine vdr.service in /etc/systemd/system für openSuSE12.1 sieht so aus:


    Damit startest du nur das bash-script, also im Prinzip nichts anderes als im klassischen System V auch. Die Vorteile von systemd wie z.B. job-control und restart-on-fail erhältst du damit nicht. Ich denke das interessante daran ist ja, dass man (oder ich zumindest) auf das Shellscript verzichten kann und stattdessen ein natives .service File hat - welches den Daemon mittels Abhängigkeiten, frischen Umgebungsvariablen, ExecStartPre/ExecStartPost, etc sauber aufsetzen und kontrollieren kann.

    Das kannst du relativ easy mit PulseAudio machen und mittels Fernbedienung die default-sink auswählen ("pacmd set-default-sink" über lirc anfeuern)


    EDIT: Ich habe ein S9-HD Headset und kann auswählen ob ich A2DP oder Sprache haben möchte, im letzteren Fall hab ich nur Mono kann aber auch das Mikrofon nutzen.

    Da ich im Forum noch nichts gefunden habe, hier meine vdr.service Datei um vdr unter systemd starten zu lassen:


    Danach ein reload und es sollte laufen:

    Quote

    [root@htpc system]# systemctl --system daemon-reload && systemctl start vdr.service

    Anmerkungen:

    • zwischen -P und Plugin-Name muss ein Leerzeichen, da systemd sonst nicht gruppiert. Alternativ ginge auch das Anfuehrungszeichen vorzuziehen, z.B. '-Pepgsearch --bla'
    • "ExecStartPost=/usr/local/bin/svdrpsend.pl remo off" brauche ich, da ich MMS gleichzeitig starte und VDR ueber ein Frontend bediene
    • um VDR beim booten zu starten genuegt ein "systemctl enable vdr.service"

    Stimmt, leider nur Anzeige der Daten, keine Steuerung :/ Module 'it87' und 'coretemp'


    Quote

    Original von ferdi03
    Linux Kernel 2.6.34-rc7
    dxr3 Treiber: 0.18.0
    VDR 1.6.0
    dxr3 Plugin: 0.2.9+ (aktueller Head vom Git Repo)


    Aber es ist doch so oder? Die Modulparameter der dxr3 Treiber sind doch nur entscheidend wenn das Bild komplett in den Farben falsch ist?! Wie gesagt bei mir passen "nur" die OSD Farben nicht.


    Ja, ist richtig. Beim dxr3-0.18.0 gab's eine Header-Aenderung, also die Header nochmal neu installieren und vdr dann nochmal neu kompilieren.

    Hallo zusammen,


    Nachdem mir meine letzte Bluetooth Maus zuoft vom Tisch gerannt ist, bin ich nun schon seit laengerem auf der Suche nach einer Neuen.


    Wichtig ist mir, dass die Maus Bluetooth hat, damit ich sie mit dem integrierten Adapter in meinem Notebook nutzen kann und dass sie per USB-Kabel zu laden ist.


    Aber gerade diese beiden Features scheinen sich gegenseitig auszuschliessen.. Ich hatte bisher eine Maus von ebay, die auch mehr oder weniger ihren Zweck erfuellt hat. Die Verarbeitung war aber nicht die beste und zudem scheint es sie nicht mehr bei ebay zu geben.


    Kennt jemand vielleicht eine solche Maus?

    frisch von der ML:


    Quote

    Original von wirbel
    Nein, die initiale Frage war: überlebt ein USB-Stick reformatting mit xfs ohne beschädigt zu werden.

    Also doch.


    Quote

    Auf dem Stick werden Kopien von binaries liegen, um die HDDs schlafen zu legen. Alles reine Lesezugriffe - wenig Schreibzugriffe = wenig Zugriffe auf das Journal. Nicht einmal im Fehlerfalle entstünden merklichen Ausfälle, da die Originale noch vorhanden sind und das BS weiterhin nicht angefasst wird. Im allerschlimmsten Falle fahre ich die NAS runter, zieh den Stick ab und reboote.

    Ok, dann ist es natuerlich herzlich egal. Das haettest du gleich ins OP schreiben sollen ;-)


    Quote

    Aber ich frage mich so langsam, woher die Vorbehalte gegen journaling fs kommen. Ich hab seit Ende 1999 schon mehrere durch: reiserfs, ext3 und z.Z. xfs. Das sind mittlerweile mal mehr als 8 Jahre ohne Datenverlust. ext3 ist nichts anderes als ein aufgebohrtes ext2.

    Siehe oben. Wir reden hier schon noch ueber den Einsatz auf USB-Sticks oder?

    Ich weiss ja nicht wie gross dein USB-Stick ist und wie oft du vorhast einen fsck durchzufuehren, aber im Normalfall sind die beiden Faktoren der Datensicherheit nachzustellen.
    Meine Posts nennen ein paar gute Gruende die gegen ein FS mit Journal sprechen (war das nicht deine initiale Frage?). Aber im Endeffekt muss das jeder fuer sich selbst entscheiden.

    Grade bei SSDs der ersten Generation und USB-Sticks arbeiten die Wear-Leveling Controller ungenuegend oder sind gar nicht erst vorhanden. Darauf wuerde ich mich auf keinen Fall verlassen. Warum willst du eigentlich unbedingt ein Journal haben?