Archiv der Kategorie: Software

Alles was mit Software zu tun hat

rtl_fm: Frequenzanzeige im Scan-Modus

Kurzer QnD-Patch zwischendurch: Möchte man mit einem RTL_SDR mehrere Frequenzen mit wenig Verkehr im Auge behalten bietet es sich an rtl_fm im Scan-Modus zu nutzen. Hierbei klappert er alle angegebenen Frequenzen ab und bleibt bei erreichen einer einstellbaren Schwelle auf dem aktuellen Kanal stehen. Von der Funktion her ähnlich wie der automatische Sendersuchlauf moderner Radios nur mit dem unterschied, dass bei Signalverlust (aka. Gegenstelle sendet nicht mehr) der Scan weitergeht. Leider hat rtl_fm hier einen Nachteil: Man sieht nicht was er tut – zwar bekommt man das Signal, kann aber nicht wirklich feststellen von welcher Frequenz es stammte. Mit folgendem Patch wird das Tool um das Argument „-v“ ergänzt. Hiermit gibt der Scan-Modus erweiterte Meldungen über den Zustand aus, namentlich „Scan…“ wenn kein Signal vorhanden ist und „Tuned to 12345Hz“ wenn er sich auf ein Signal eingependelt hat. Die Ausgaben erfolgen über stderr und beeinträchtigen daher nicht den eigentlichen Audiostrom.

Disclaimer wie üblich: Ich bin nicht wirklich im C-Bereich unterwegs, der Code könnte möglicherweise Fehler enthalten welche euren Rechner in ein katzenfressendes Monster verwandeln.

Arch Linux: tmpfs-Bootfehler nach Systemd-Upgrade

War ja klar – gerade erst vom 30c3 zurück und schon die ersten Probleme: Auf meinem Hauptrechner hatte ich vor Abfahrt noch schnell ein Update gemacht, welches auch Systemd betraf. Bei jetzt erfolgtem, ersten Start nach dem Update hing sich das System im Bootvorgang auf:

timed out waiting for device tmpfs.device

Ursache war eine Performanceoptimierung meinerseits: /tmp liegt nicht auf einem Datenträger sondern per tmpfs im RAM. Offenbar war ich aber damals etwas zu schnell bei Copy&Paste, denn meine /etc/fstab-Zeile sah so aus:

tmpfs /tmp tmpfs defaults,nodev,nosuid 0 1

Die letzte 1 besagt, dass das System ein fsck, also Dateisystemcheck, beim Boot durchführen soll. Bisherige Systemd-Installationen ignorierten die Angabe, da tmpfs einerseits beim Boot leer ist und andererseits kein fsck-Befehl für dieses virtuelle Dateisystem existiert. Mit der neuen Version tritt obiger Fehler auf. Fix ist recht einfach: Per Boot-CD oder ohne init.d starten (init=/bin/bash als Kernel-Argument), die Root-Partition schreibbar mounten (mount -o rw /dev/sd** /mnt bzw mount -o remount,rw /) und in der /etc/fstab die letzte 1 der tmpfs-Zeile(n) gegen eine 0 ersetzen.

Linux auf Acer Aspire One ZG5: Kernel-Panic durch SD-Leser

Offenbar gibt es eine Regression in den letzten Linux-Kerneln(vermutlich 3.12.x): Auf oben genannten System kam es alle paar Minuten zu unerklärlichen Kernel-Panics. Im Trace war öfter die Rede vom sdhci-Modul, welches für die SD-Leser zuständig ist. Auslöser ist höchstwahrscheinlich der Slot an der linken Seite – die rechte Seite nutzt PCI-Hotplug und ist ohne Karte dem System nicht bekannt. Betroffen sind vermutlich beide Seiten, zwar ist der rechte durch PCI-Hotplug ohne Karte von System getrennt, jedoch werden beide Controller als „JMicron Technology Corp. Standard SD Host Controller“ erkannt.

Als Workaround kann man – bis der Fehler behoben ist – den SD-Card-Leser abschalten, hierzu wird folgendes Kernel-Argument genutzt:

modprobe.blacklist=sdhci,sdhci_pci

Im Fall von Grub2 auf Archlinux kann es z.B. in /etc/defaults/grub als GRUB_CMDLINE_LINUX hinterlegt werden. Logischerweise lassen sich bis der Fehler behoben ist keine SD-Karten im Gerät nutzen.

WordPress: Kategorien aus RSS-Feed ausschließen

Dank eines Hinweises von Jakob fand ich noch ein Problem auf dieser Seite, welches mit reclaim.fm zusammen hängt. Ich spiele (fast) alle meine Social-Media-Inhalte auch im Blog ein. Da sie in eigenen Kategorien landen lässt sich das Ganze recht einfach filtern: Alles aus dieser Ecke wird nicht als Blogpost angezeigt – dachte ich. Leider landeten die Einträge weiterhin im RSS-Feed, was natürlich nicht Sinn der Sache war.

Um die Änderungen halbwegs konsistent zu behalten sollte das Ganze vorzugsweise im Theme eingebracht werden. Dank web-kreation.com war der fehlende Tipp schnell ergoogled. Mit einer kleinen Änderung werden die Kategorien nur ausgeblendet wenn keine anderen Filter aktiv sind, so sollte imo nur der Hauptfeed von den Ausnahmen betroffen sein.

Hier der Code, welcher in die functions.php des Themes eingebracht werden muss:

function filter_social_rss($query) {
  if ($query->is_feed && $query->get('cat') == '' && $query->get('tag') == '') {
    $query->set('cat','-240,-241,-178,-242');
  }
  return $query;
}

add_filter('pre_get_posts','filter_social_rss');

MySQL-Fehler: XMBC/OpenELEC lässt keine Änderungen an der Filmdatenbank zu

Narf? Muss das sein? Beim automatischen Import meines neu sortierten TV-Aufnahmen-Speichers ist in XMBC bzw. OpenELEC so einiges nicht ganz da gelandet, wo es sollte. A Clockwork Orange von 2013? Guess not.

Keine große Sache, oder? Einfach manuell aktualisieren und den richtigen Eintrag auswählen, schon wird alles aktualisiert, so weit die Theorie. In der Praxis landete ich wieder auf der selben, falschen Detailansicht.

Schuld war meine MySQL-Datenbank, diese liegt – da ich mehrere XMBCs betreibe – auf einem zentralen Server. In der Log-Datei (/storage/.xbmc/temp/xbmc.log) fand sich folgende Zeile:

ERROR: SQL: Undefined MySQL error: Code (1548)
Query: delete from movie where idMovie=146
ERROR: DeleteMovie failed

Hm – strange, also auf in phpMyAdmin und nachgeschaut. Ein Film mit idMovie=146 existiert, so weit so gut, aber auch hier funktioniert der Delete nicht und vermeldet:

Cannot load from mysql.proc. The table is probably corrupted

Schuld sind die integrierten Trigger/Funktionen/… der XMBC-Datenbank in Kombination mit einem verpennten Update. Der MySQL-Server selbst wurde eine Version hochgezogen, die Datenbanken aber nicht aktualisiert. Ein einfaches

mysql_upgrade

(ggf. mit -uroot -p) bringt alles auf den neuesten Stand und die MediaDB kann wieder bearbeitet werden.

PHP (Linux, CLI) clear screen

Wenn man PHP auf der CLI nutzt könnte man in die Versuchung kommen den Bildschirm leeren zu wollen, also in etwa das selbe, was der Linux-Befehl „clear“ macht. Da bei exec (so vermute ich) die Termcaps nicht übergeben werden funktioniert ein exec(‚clear‘); nicht sonderlich. Wenn man immer das selbe Terminal nutzt lassen sich die nötigen Steuerzeichen direkt als echo hinterlegen. Um die Zeichen zu ermitteln loggt man sich normal auf der gewünschten Konsole ein und startet „clear | xxd“ – hier sieht man die für das aktuelle Terminal nötigen Steuerzeichen in Hex. In meinem Fall

0000000: 1b5b 481b 5b32 4a .[H.[2J

in PHP verpackt ergibt sich dann (ausgeschrieben) folgende Zeile:

echo chr(0x1b) . chr(0x5b) . chr(0x48) . chr(0x1b) . chr(0x5b) . chr(0x32) . chr(0x4a);

Symantec Backup Exec (RALUS) auf Arch Linux

Symantec hat für ihr Produkt „Backup Exec“ auch einen Agenten im Angebot, welcher die Sicherung von Linux- und Unix-Systemen ermöglichen soll. Dieser so genannte „Remote Agent for Linux and Unix Servers“ aka RALUS hat leider eine sehr eingeschränkte Kompatibilitätsliste. Zwar gibt es im Netz einige Anleitungen für Debian, für Arch wurde ich aber nicht fündig. Nach ein paar Versuchen war mir die Herkunft der Paketbeschreibung eines Repos für CENTOS auch klar:

It is a crappy tool and you should seriously consider not using it.

Nicht nur, dass die Installationsdaten lediglich versteckt als deb und rpm vorliegen: Teile der Config werden über ein Wirrwarr an Perl-Scripten generiert und bei der Nutzung mit Kerneln >=3 muss man am Kernel oder im Binärcode herumpatchen. Great!

Nungut, inzwischen läuft der Daemon, ein passender PKGBUILD für die mir vorliegende Version (14.0.1798-0, 64 Bit) ist auf Github zu finden. Mit drin ist der Binärpatch für Kompatibilität mit Kernel 3.x sowie etwas Rechtefoo. Da das Ganze mehr eine Vorlage als funktionsfähiges PKGBUILD darstellt wandert’s erst mal nicht ins AUR.

ext4 vs. BTRFS – mal wieder

OK, ok, zugegeben, das Thema gibt’s zu Hauf im Netz, aber ich vertraue lieber eigenen Zahlen: Was ist schneller: ext4 oder btrfs? Hintergrund ist ein Backupzwischensystem, welches große Datenmengen schnell verarbeiten muss. Die Kompression von BTRFS wäre angesichts der Kosteneinsparung durch weniger Plattenverbrauch ein schöner Bonus, aber darf nicht auf Kosten der Geschwindigkeit gehen.

Das System ist ein „Low-End“ Dualcore (Intel(R) Pentium(R) CPU G645 @ 2.90GHz) mit 16GB RAM und 4 Hitachi Deskstar 5K3000 á 2TB. Die Platten mit 5300rpm sehen zwar auf den ersten Blick etwas schwachbrüstig aus, da die Daten aber vermutlich sehr groß und entsprechend hoffentlich am Stück geschrieben werden sollte die geringe Drehzahl hoffentlich nicht wirklich ins Gewicht fallen. Das Mainboard (ASRock H77 Pro4/MVP) verfügt über zwei SATA-Controller – der Intel® H77 steuert neben 4 SATA2-Ports zusätzlich 2 Ports mit SATA3 bei, ein ASMedia ASM1061 stellt 2 zusächliche SATA3-Ports bereit. Die Platten wurden über die SATA3-Ports an beide Controller verteilt.

Die Tests liefen auf einem Arch Linux x86_64-System mit Kernel 3.11.2, als RAID kam das im Kernel enthaltene md-Framework zum Einsatz, auf die bei BTRFS integrierte RAID-Funktion verzichte ich, da ich separate Schichten für besser wartbar halte.

Erst einmal die rohen Werte der Platte: Diese lieferten im Test jeweils etwa 140MB/s sequential Read.

Erster Versuch: 1GB sequential Write, die Platten werden dabei erst mal als RAID5 genutzt, in der Hoffnung, dass die Geschwindigkeit noch ausreichend ist. Das Ergebnis ist etwas ernüchternd:

1GB Sequencial File Write
RAID5, EXT4 99MB/s
RAID5, BTRFS 134MB/s
RAID5, BTRFS (LZO) 144MB/s

BTRFS liegt zwar klar vor ext4 und auch die Kompression bringt auf Grund der gut komprimierbaren Quelle einen Geschwindigkeitsschub, insgesamt liegt die Leistung aber unter meinen Anforderungen – 144MB/s könnte die 2GBit/s Uplink grade so bewältigen, aber eigentlich hätte ich schon gerne noch etwas Reserve… Die Antwort dürfte klar sein: Da die Daten hier nur zwischengelagert werden bin ich auf das RAID5 nicht angewiesen, also RAID0 ftw – der erste Blick aufs rohe Device ist vielversprechend: 490MB/s sind ein guter Start – und was machen die Dateisysteme daraus?

RAID0, EXT4 349MB/s
RAID5, BTRFS 376MB/s
RAID5, BTRFS (LZO) 382MB/s

Viel ändert sich nicht – BTRFS mit Kompression erreicht gegenüber ext4 knapp 10% höhere Schreibraten. Die 380MB/s dürften erst bei etwa 4GBit/s uplink an ihre Grenzen stoßen – bis die fällig sind dürfte eher der Plattenplatz ausgehen. Sieger gefunden würde ich sagen: BTRFS schlägt ext4 sowohl bei Geschwindigkeit als auch beim Funktionsumfang – ob es auch die Stabilität der ext-Systeme nacheifern kann wird die Zeit zeigen.

Hinweis zum Gentoo-Update auf www-apps/owncloud-5.0.12

Kurzer Hinweis zu letzten Owncloud-Update unter Gentoo: Durch eine nicht ganz performante Funktion scheint das ebuild in der Install-Phase zu hängen. Auf einem Atom-System dauerte es 2 Stunden bis Portage den Vorgang abschließen konnte, auf einem i7 mit RAID 15 Minuten, also nicht ungeduldig werden und nach Anstoßen des Updates doch erst mal eine (Familien)Pizza essen gehen. Der Installationsvorgang kann mit lsof auf den Temp-Ordner (/var/tmp/portage/) beobachtet werden.