Archiv der Kategorie: Software

Alles was mit Software zu tun hat

Software

Renicetree – renice a process including it’s children

Schreibe einen Kommentar

./configure && make – aw crap.

Immer wieder passiert es mir, dass ich längere Prozesse starte ohne ein „nice“ davor zu setzen. Ergebnis: Der Kompiliervorgang o.Ä. hat die selbe Priorität wie alles andere und zieht die Reaktionsfähigkeit des PC deutlich in den Keller. Üblicherweise kann man nun mir „renice“ den Prozess nachträglich herunterstufen, jedoch klappt das gerade bei Kompiliervorgängen nicht sonderlich gut: renice ändert lediglich die Priorität des angegebenen Prozesses, hierdurch werden auch neu erstellte Kindprozesse erfasst, bereits laufende jedoch nicht. Da Make teils sehr verschachtelt arbeitet und Jobprozessoren zur Verteilung der Aufträge nutzt muss man z.T. einige Prozesse ändern um das System wieder lauffähig zu machen. Hier z.B. der make-Baum eines OpenWRT:

make(25087)->sh(25209)->make(25211)-|->bash(25214)->make(25237)
                                    |->bash(25229)->make(25240)

Da ich keine Lust mehr hatte ständig die nötigen IDs per Hand zu suchen ist renicetree entstanden. Es sucht alle zu einer PID gehörigen Kindprozesse und setzt auch für diese ein renice ab. Um halbwegs kompatibel zu bleiben ist die Software in einer Bash-Syntax entstanden.

Da ich keinerlei erweiterte Ahnung von Shell-Scripting habe dürfte der Code bei Profis vermutlich Haarraufen verursachen, aber er läuft immerhin – auch wenn mir die Eigenheiten der Bash gewaltig auf den Nerv gingen (Keine mehrdimensionalen Arrays, keine indirekte Variabelreferenzen, etc). Script gibt’s wie immer auf Github. Use at your own risk.

Update: Ich wurde darauf hingewiesen, dass renice über die Process Group ID (-g) eine ähnliche Funktion bereits bieten würde. Das kann ich – zumindest für GUI-Betrieb – nicht bestätigen, hier hat z.B. alles unter meinem Terminal-Emulator die selbe Gruppen-ID, also auch Prozesse, welche in einem anderen Tab gestartet sind.

Software

Lahmendes WordPress – eine Ursachensuche…

Schreibe einen Kommentar

Wer in den letzten Wochen auf meinem Blog unterwegs war hat es eventuell gemerkt: Irgendwie war das Ganze etwas zäh. Jeder Aufruf dauerte mindestens 5 Sekunden – nur warum?

Also gehen wir die große Frage an: Was ist der Auslöser. Frage einfach, Antwort kompliziert. Erster Anlaufpunkt: das Netz. Um zu prüfen, dass das Problem wirklich am Server und nicht am Netzwerk liegt wird die Seite lokal aufgerufen:

time wget -O - https://adlerweb.info/ > /dev/null 
[…]
real	0m5.488s
[…]

Danke, keine weiteren Fragen, am Netz liegt es nicht. Wenn wir aber schon mal da sind rufen wir auch einen statischen Inhalt auf – nehmen wir z.B. einfach mal ein Bild:

time wget -O - https://adlerweb.info/blog/wp-content/uploads/2014/05/header-2014.png > /dev/null
[…]
real	0m0.017s
[…]

Aha – der statische Aufruf funktioniert zügig, damit wäre ein Fehler des Webservers selbst eher unwahrscheinlich. Der PHP-Interpreter oder die Anwendung scheint also Auslöser zu sein. Testen wir mal eine „rohe“ PHP-Datei. Reines echo.

time wget -O - https://adlerweb.info/test.php > /dev/null
[…]
real	0m0.007s
[…]

Somit wäre auch der PHP-Interpreter raus – es kann also eigentlich nur noch WordPress sein, oder? Nunja, ein reines WordPress auf selbem Server ist da anderer Meinung:

time wget -O - https://adlerweb.info/wptest/ > /dev/null
[…]
real	0m0.895s
[…]

Deutlich langsamer als der Testcode, aber es sind ja auch ein paar Zeilen mehr – eine Sekunde ist aber imo noch erträglich. Also muss irgendwas in der Seite den Fehler verursachen – Plugins, Themes, Anpassungen. Viele Kandidaten.

Erster Versacht: Meine Solarstatistiken. Diese müssen sich erst durch meinen heimischen Anschluss quetschen und der ist nicht gerade der schnellste. Statistik aus, aber trotzden: 4.925s. Kein Wunder: Es sind ja nur wenige Zeichen Text und spätestens beim zweiten Aufruf wären sie im Cache des Servers. Also weiter geht die Deaktivierungsorgie, aber mit Nachbrenner.

Um herauszufinden ob ein Plugin oder sonstiger Code das Problem verursacht wandern alle Plugins temporär aus dem WordPress-Ordner in ein temporäres Verzeichnis. Bingo: Ohne Plugins lädt die Seite in gerade mal 0.265s – suchen wir den Schuldigen. Plugin für Plugin wird dieser eingerichtet, dabei stechen einige hervor:

– apc: +1,2 Sekunden
– wp-slimstat +0,3 Sekunden

APC war früher als Cache im Einsatz, heute ist das Plugin im Backend deaktiviert, aber durch einen damals nötigen Symlink werden offenbar trotzdem Teile des Plugins geladen. Die Ladezeit steigt dabei offenbar mit der Codegröße – wenn mehr andere Plugins geladen sind erhöht sich die Ladezeit mit APC prozentual. Wie schon gesagt: Historie – kurze Sache: Weg damit.

WP-Slimstat ist ebenfalls etwas auffällig, wenngleich weit entfernt von der Bremswirkung des vorherigen Kandidaten. Slimstat sah mir nach einer guten Idee aus – der Webserver anonymisiert bereits die IPs, entsprechend kann ich hiermit lokale & anonyme Statistiken generieren. Den Performance-Impact hatte ich mir allerdings nicht ganz so groß vorgestellt, als Alternative hat sich jetzt WordPress Statistics von Mostafa Soufi eingefunden – mit diesem Plugin kann ich keien messbare Verschlechterung feststellen.

Ergebnis des Frühjahrsputzes (a2b, 100 Requests, 10 Parallel):

Vorher:				Ohne APC:			Andere Stats

100 Requests			100 Requests			100 Requests
146.809 seconds			24.047 seconds			14.385 seconds
6282600 bytes			6282600 bytes			6240100 bytes
42.08 Kbytes/sec		256.91 Kbytes/sec		426.60 Kbytes/sec
===================		==================		==================
1468.093 ms/Request		240.471 ms/Request		143.846 ms/Request
0.68 Requests/sec		4.16 Requests/sec		6.95 Requests/sec

Durch löschen des alten Plugins konnte die Ladezeit um 83% gesenkt werden – mit neuem Statistikplugin waren sogar weitere 7% Reduktion möglich. Ein zehntel der Ladezeit – nicht schlecht für eine eigentlich so kleine Ursache…

Wir lernen: Man sollte öfter mal aufräumen, nicht mehr verwendete Plugins auch aus dem Dateisystem entfernen und Plugins vor der Nutzung vergleichen…

Hardware, Software

Intel Haswell-ULT Integrated Graphics: TFT-Backlight reagiert langsam

Schreibe einen Kommentar

Auf einem Laptop mit Intel Haswell-ULT GPU hatte ich das Phänomen, dass jede Änderung der TFT-Beleuchtungsstufe das System für etwa eine Sekunde einfrieren lies. Besonders ärgerlich, wenn dies wegen Inaktivität automatisch veranlasst wurde, denn in diesem Fall wird ein Fade-Effekt mit mehreren Stufen gefahren – und der Laptop so für etwa 20 Sekunden unbenutzbar.

Auffällig bei diesem Gerät: In /sys/class/backlight/ sind gleich 2 Schnittstellen gelistet: acpi_video0 und intel_backlight. Erstere zeigt das beobachtete Delay, letzeres reagiert ohne spurbare Verzögerung. Um den X.Org-Automatismen die schnellere Schnittstelle ans Herz zu legen muss in /etc/X11/xorg.conf.d/20-intel.conf oder anderer passender Stelle folgender Code gesetzt werden:

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "Backlight"  "intel_backlight"
EndSection
Hardware, Software

Intel Core i-Prozessoren und die Govenors

Schreibe einen Kommentar

Unter Linux wird/wurde die Frequenz der Prozessoren bisher durch das cpufreq-Backend des Kernels geregelt. Es gab verschiedene „Govenors“, welche je eine Eintscheidungsart implementierten. Beispiel:

ondemand CPU auf kleinster Taktfrequenz, wird bei Last erhöht
performance CPU immer auf maximaler Taktfrequenz
powersave CPU immer auf kleinster Taktfrequenz

Mit den neuen Core i-Prozessoren (i3,i5,i7) ist dieses Konzept nur noch bedingt brauchbar – die CPU selbst hat viele Mechanismen um Strom zu sparen, sie muss allerdings „aufwachen“ um über den Govenor entscheiden zu können, ob die Beschäftigt ist oder nicht. Da hierdurch die dynamische Frequenzregelung am Ende mehr Strom verbraucht als ein Prozessor, welcher sich auf höchster Taktrate selbst verwaltet, bieten neue Kernel nun nur noch powersave oder performance für diese Prozessoren an. Für Intel empfiehlt sich „powersave“ zu wählen, durch die TurboBoost-Technologie erhöht die CPU ihren Takt bei entsprechender Last selbstständig. Mit Tools wie z.B. i7z lässt sich die Frequenzänderung auch entsprechend beobachten.

tl;dr: Intel-CPUs nur mit powersave-Govenor betreiben, CPU regelt Takt selbst passend hoch.

Software

Gentoo: Linker-Fehler bei alten Paketen mit neuer GLibc

Schreibe einen Kommentar

Möchte man alte Pakete auf einem System mit neuerer GLibc nutzen kommt es u.U. beim Linknen zu kleineren Verstimmungen:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined in DSO /lib64/libm.so.6 so try adding it to the linker command line 
/lib64/libm.so.6: could not read symbols: Invalid operation 
collect2: error: ld returned 1 exit status

Als Workarround kann man die nötige Lib über paketspezifische LDFLAGS händisch einbinden:

/etc/portage/enc/templd.conf

LDFLAGS="$LDFLAGS -lm"

/etc/portage/package.env:

bla-foo/bar   templd.conf

Via nlsa8z6zoz7lyih3ap @ Gentoo Forums

Software

IE11: Intranetseiten werden nicht korrekt dargestellt

Schreibe einen Kommentar

Kurzer Hinweis an alle, die neuere Webapplikationen in einem Windows-Intranet nutzen wollen: Je nach Einstellung werden Webseiten mit internen IPs/Hostnames bei Nutzung des IE 11 automatisch in der „Kompatibilitätsansicht“ gerendert. Als Beispiel verschluckt sich daran die JS-Komponente des Vorlkszählers und zeigt folgende Meldung:

„Die Eigenschaft „forEach“ eines undefinierten oder Nullverweises kann
nicht abgerufen werden.“

Der Fehler scheint in diesem Fall nur mit dem IE11 im Kompatibilitätsmodus aufzutreten, der IE10 rendert trotz der Einstellung korrekt.

Mögliche Auswege:

a) Kompatibilitätsmodus abschalten

Unter Extras->Einstellungen der Kompatibilitätsansicht die Option
„Intranetsites in Kompatibilitätsansicht anzeichen“ abschalten

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/05/intranet-241×300.png

Vorsicht: Dies kann ggf. andere intern verwendete Webapps unbrauchbar machen
– ask your Admin…

b) Auf der Webseite explizit IE11-Modus fordern

Hierzu folgendes im Header ergänzen:

Beim Volkszähler wäre der Code in /htdocs/frontend\index.html.

Alternativ gibt es auch passende Doctypes oder HTTP-Header um den IE zur Zusammenarbeit zu bewegen.

Software

Linux-Shell/Bash: Passwörter einlesen (read)

Schreibe einen Kommentar

Ab und an benötigen Scripte schon mal Passwörter für andere Systeme. Meist finden sich die Passwörter hardcoded im Script oder werden per Argument mitgegeben. Beide varianten haben den Nachteil, dass die Passwörter im Script oder der passenden Log-Datei (z.B. .bash_history) ggf. lesbar sind.

Bei interaktiv genutzten Scripten lässt sich mit „read“ das Passwort in eine Variable einlesen. Mit -s kann das echoing, also die Ausgabe des Passworts während des Eintippens, unterbinden.

read -s -p "Passwort fuer Nutzer123? " pwd
./befehl -u Nutzer123 -p "${pwd}"
Software

Aria2 als Daemon mit Webinterface unter Arch Linux

Schreibe einen Kommentar

Kurz und knapp: Aria2 ist ein Downloadmanager für Linux, welcher ein sehr großes Funktionsspektrum bietet – Downloads werden per HTTP/HTTPS, FTP, BitTorrent oder Metalink abgewickelt. Im HTTP-Bereich ist es möglich Downloads in mehrere Parts zu stückeln und diese von verschiedenen Mirror-Servern zu laden.

In meinem Fall soll das Ganze auf einem (GUI-losen) Linux-System laufen und von einem PC verwaltbar sein – so kann z.B. die neue Linux-Distro gemächlich über meine alte DSL-Leitung vor sich hin laden ohne meine Kabel-Hauptleitung zu belasten oder mich zu Zwingen den Rechner durchlaufen zu lassen. Als Host genügt dabei durchaus ein Linux-Embedded-System wie z.B. viele Router oder auch der Raspberry Pi.

Aria2 findet sich in den offiziellen Arch-Repos und lässt sich entsprechend direkt installieren. Für den Daemon-Modus nutze ich einen eigenen Benutzer namens „aria2“. Im Home-Verzeichnis des Nutzers wird (wenn nicht vorhanden) ein Ordner .aria2 erstellt (führenden Punkt nicht vergessen). Dort wiederum eine Datei namens aria2.daemon mit folgendem Inhalt:

continue
daemon=true
dir=/home/aria2/Downloads
file-allocation=falloc
log-level=warn
max-connection-per-server=4
max-concurrent-downloads=3
max-overall-download-limit=0
min-split-size=5M
enable-http-pipelining=true

enable-rpc=true
rpc-listen-all=true
rpc-user=rpcuser
rpc-passwd=rpcpass

Die Konfiguration weist Aria2 an als Daemon zu starten und alle Downloads in /home/aria2/Downloads zu speichern. Pro Server werden maximal 4 Verbindungen geöffnet, insgesamt 3 Downloads werden parallel geladen. Eine Bandbreitenbeschränkung für den Download ist nicht hinterlegt. In den letzten Zeilen werden die Zugangsdaten für das Frontend hinterlegt.

Anm: rpc-user und rpc-pass sind „deprecated“ und sollten nicht mehr verwendet werden, zum aktuellen Zeitpunkt wurde das hier verwendete Frontend jedoch noch nicht auf die neue Authentifizierungsmethode portiert

Anm2: file-allocation=falloc weist aria2 an den für den Download nötigen Platz im Vorfeld zu reservieren, dies verhindert Fragmentierung der Daten, jedoch kann es beim Start des Download einige Sekunden bis Minuten dauern bis die ersten Daten übertragen werden. falloc ist nur auf neueren Dateisystemen wie ext4, btrfs oder xfs nutzbar, bei älteren Systemen kann prealloc genutzt werden. Mit none wird die Reservierung abgeschaltet.

Um den Daemon automatisch beim Boot zu starten wird zudem die Datei /etc/systemd/system/aria2c.service erstellt:

[Unit]
Description=Aria2c download manager
After=network.target

[Service]
Type=forking
User=aria2
RemainAfterExit=yes
ExecStart=/usr/bin/aria2c --conf-path=/home/aria2/.aria2/aria2.daemon

[Install]
WantedBy=multi-user.target

Auch hier ggf. die Pfade an das eigene Setup anpassen.

Per systemctl start aria2c wird der Dienst gestartet – läuft dies ohne Fehlermeldung kann er mit systemctl enable aria2c in den „Autostart“ des Servers gelegt werden. Alles ist auch nochmal in der Arch-Wiki zu finden.

Für das Webinterface verwende ich webui-aria2. Es nutzt ausschließlich Javascript/HTML5 (Websockets/AJAX) für die Kommunikation, daher ist es weder notwendig die Daten auf dem selben System abzulegen, PHP/Python/Perl… zu installieren oder einen Webserver zu nutzen. Theoretisch kann die Datei auf der lokalen Festplatte des verwaltenden PCs/Laptops liegen und dort geöffnet werden. In meinem Fall liegen die Dateien auf einem bereits vorhandenen Webserver, so muss ich bei Updates nicht immer zwischen all meinen Geräten hin und her kopieren.

Beim öffnen der HTML-Datei werden die Zugangsparameter abgefragt. Bei Host wird die IP des Servers mit Aria2 eingetragen, der Port ist bereits hinterlegt. User/Passwort wurden in der zuvor erstellten Konfigurationsdatei eingerichtet.

Im Anschluss sollte die Verbindung aufgebaut werden können – am besten Prüft man das über Settings->Server Info, sind hier Daten hinterlegt konnte die Verbindung aufgebaut werden. Lasset die Downloads starten!

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/05/aria2-300×195.png

Downloads direkt auf einem kleinen Linux-System? Check.

Zur Referenz: Der gezeigte Download ist Star Trek Phase II: Kitumba von startrekphase2.de.

Software

PHP: Gekürzte var_dump()-Ausgaben abschalten

Schreibe einen Kommentar

„Mal schnell“ ein paar Daten im PHP-Code lesbar ausgeben funktioniert üblicherweise sehr zuverlässig mit var_dump(). Auf einem System zeigte sich das Phänomen, dass lange Strings oder verschachtelte Arrays nicht vollständig angezeigt wurden. Ursache ist die Standardkonfiguration vieler Distros der PHP-Extension xdebug. In der entsprechenden ini-Datei lässt sich das Kürzen mit folgenden Zeilen unterbinden:

xdebug.var_display_max_data=-1
xdebug.var_display_max_children=-1
xdebug.var_display_max_depth=-1

Software

Gentoo: tcpdump -w kann keine Dateien schreiben / Dateien nicht auffindbar

Schreibe einen Kommentar

Mit tcpdump kann man sehr einfach auf der Konsole Netzwerkverbindungen mitlesen und so Fehler genauer betrachten. Üblicherweise lässt sich mit der Option „-w datei.pcap“ dieser Mitschnitt auch als pcap-Datei speichern, welche beispielsweise mit Wireshark geöffnet und weiter analysiert werden kann.

Unter Gentoo zeigten sich heute 2 seltsame Verhaltensmuster:

Mit absoluten oder relativen Pfaden:


tcpdump -i br0 -w /tmp/test.pcap
tcpdump: /tmp/test.pcap: No such file or directory

Ohne Pfad erscheint keine Fehlermeldung, die Datei wird aber augenscheinlich auch nicht erstellt:


host tmp # tcpdump -i br106 -w test.pcap
tcpdump: WARNING: br106: no IPv4 address assigned
tcpdump: listening on br106, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel
host tmp # ls -l test.pcap
ls: cannot access test.pcap: No such file or directory
host tmp #

Auslöser ist das USE-Flag „chroot“ – hierdurch wird der Prozess in ein virtuelles Root gesperrt, sodass Fehler (hoffentlich) nicht zu viel Schaden anrichten können. Alle Pfade beziehen sich auf /var/lib/tcpdump/ – entsprechend sind dort auch die ohne Pfadangabe generierten pcap-Dateien zu finden.