We have a commercial piece of software here that can cause an irrecoverable kernel panic when starting, by loading a proprietary kernel module. Detect whether the system was previously shut down cleanly and fail the service, if not:
# /etc/systemd/system/fouled-up.service.d/prevent.conf
[Service]
ExecStartPre=echo 'Analyzing journal for clean shutdown on previous boot.'
ExecStartPre=journalctl -b -1 -g 'Shutting down.' _COMM=systemd
ExecStartPre – Fail the unit if this command fails.
journalctl -b -1 – Look at entries from previous boot.
-g 'Shutting down.' – Grep for entries containing this string. Returns non-zero if not found.
_COMM=systemd – Match entries from this command only.
Gnome session keyring / Seahorse CLI interaction
Nobody seems to really know how this works. I do however have an application password that I want to keep in the Gnome session keyring.
The documentation for secret-tool references attributes/keys and values, but there seem to be no predefined names or convention for this.
How to save and retrieve a password in the Gnome session keyring:
Ratarmount is an excellent tool for mounting archives as filesystems, and I use it a lot. Mostly for union-mounting tar.xz telemetry bundles created by sos report. The ratarmount README suggests to prefer indexed tar.xz archives created using pixz for performance, so let’s see what’s the best compression to use.
TL;DRs
On huge archives, tar.gz is always fast and fastest, no optimization required.
Best to recompress tar.xz to tar.gz for best performance. Recompressing with pixz yields an improvement, but not as much as gzip.
On tiny archives close to the host’s RAM size, performance is hard to predict and may put gzip behind.
The “Backup” use-case
For my test to have a bit of a sizable workload, I pick a reasonably-sized tar.gz, a remnant historical backup of a long-gone server:
-rw-r----- 1 root root 1.7G Aug 6 10:16 example.tar.gz
This is stored on a RAID-1 of 7200 rpm hard drives, which should amplify all seek performance issues. 8 GB RAM, 6 physical CPU cores, 12 threads.
I prepare a list of 1000 random files from the archive that I’ll be reading from the mounted archive.
tar ztf example.tar.gz | egrep -v '(/$|(sys|proc|dev|run))' | shuf | head -1000 > example.list
Now, I mount the tar.gz for my baseline measurement.
umount ./mnt; ratarmount example.tar.gz ./mnt
time xargs -I{} md5sum ./mnt/{} < example.list
...
real 0m13.974s
user 0m1.178s
sys 0m0.984s
I recompress the tar from gzip to pixz and measure again:
gzip -dc example.tar.gz | pixz > example.tar.pxz
umount ./mnt; ratarmount example.tar.pxz ./mnt
time xargs -I{} md5sum ./mnt/{} < example.list
...
real 0m57.408s
user 0m1.216s
sys 0m0.904s
Multiple times slower! Back to ratarmount‘s README: “In contrast to bzip2 and gzip compressed files, true seeking on XZ and ZStandard files is only possible at block or frame boundaries.” – Are you telling me gzip is not the issue and only naively compressed xz is? A quick recompress using vanilla xz and a comparison of that to the pixz compressed archive:
gzip -dc example.tar.gz | xz --threads=$(nproc) > example.tar.xz
umount ./mnt; ratarmount example.tar.xz ./mnt
time xargs -I{} md5sum ./mnt/{} < example.list
...
real 1m33.549s
user 0m1.109s
sys 0m0.838s
Indeed a noticable, although not huge, penalty compared to pixz. Now that I’m here and wasted this much time, a final measurement using bzip2:
gzip -dc example.tar.gz | bzip2 > example.tar.bz2
umount ./mnt; ratarmount example.tar.bz2 ./mnt
time xargs -I{} md5sum ./mnt/{} < example.list
...
real 0m44.410s
user 0m1.301s
sys 0m1.164s
So ratarmount handles bzip2 around the same speed as xz created by pixz.
Gzip is always fastest, even without any special treatment, and I assume this is because multi-threaded rapidgzip literally is ratarmount’s sister project.
The “Telemetry” use-case
Back to my tiny sosreport files in tar.xz format, still on the 7200-rpm HDD system. For consistency, I’ll use the same md5sum benchmark on 1000 archive members as above.
ls -lh sosreport.tar.xz
-rw------- 1 root root 9.3M Aug 14 16:07 sosreport.tar.xz
tar Jtf sosreport.tar.xz | egrep -v '(/$|(sys|proc|dev|run))' | shuf | head -1000 > sosreport.list
umount ./mnt; ratarmount sosreport.tar.xz ./mnt
time xargs -I{} md5sum ./mnt/{} < sosreport.list
...
real 0m4.979s
user 0m0.940s
sys 0m0.625s
A conversion to pixz:
xz -dc sosreport.tar.xz | pixz > sosreport.tar.pxz
umount ./mnt; ratarmount sosreport.tar.pxz ./mnt
time xargs -I{} md5sum ./mnt/{} < sosreport.list
...
real 0m6.847s
user 0m0.829s
sys 0m0.553s
And a conversion to tar.gz:
xz -dc sosreport.tar.xz | gzip > sosreport.tar.gz
umount ./mnt; ratarmount sosreport.tar.gz ./mnt
time xargs -I{} md5sum ./mnt/{} < sosreport.list
...
real 0m13.202s
user 0m0.918s
sys 0m0.598s
gzip is suddenly slower here, and I believe it’s because the file turned out more than 50% larger than the xz versions, both of which are close to the hosts’s RAM size of 8 GB:
-rw-r--r-- 1 root root 14M Aug 14 16:17 sosreport.tar.gz
-rw-r--r-- 1 root root 7.8M Aug 14 16:16 sosreport.tar.pxz
-rw------- 1 root root 9.3M Aug 14 16:07 sosreport.tar.xz
My initial notes on how to install ratarmount in a python virtualenv are documented in Too good to #0013.
Cobbled this up for putting a 1993 vintage RS/6000 into perspective. Counts how many rand() / (rand() + 1) divisions the system will do in 10 second intervals.
Die Morning Midas war ein Frachtschiff beladen mit Autos, das ab dem 26. Mai 2025 auf dem Weg von China nach Mexiko war. Am 3. Juni 2025 geriet es im Nordpazifik in Brand und die Crew konnte nach erfolglosen Löschversuchen von einem vorbeikommenden Frachtschiff aufgenommen werden. Es gab keine Toten oder Verletzten.
Am 16. Juni meldete die US Coast Guard, das Feuer auf dem führerlosen Schiff sei erloschen.
Am 24. Juni wurde dann schließlich der Untergang der Morning Midas am Tag zuvor gemeldet.
Autos an Bord
Die Ladung der Morning Midas setzte sich nach Meldungen der US Coast Guard wie folgt zusammen:
3048 Fahrzeuge insgesamt
70 batterieelektrische Fahrzeuge
681 Fahrzeuge mit Hybridantrieb
Daraus abgeleitet also: 2297 reine Verbrennerfahrzeuge und 2978 Fahrzeuge mit Verbrennungsmotor.
Zum Tankinhalt der 2978 Fahrzeuge mit Verbrennungsmotor kamen 1880 Tonnen(!) fossiler Betriebsmittel für das Schiff selbst, die beim Untergang – noch – nicht in die Umwelt ausgetreten waren.
Brandwahrscheinlichkeit pro Antriebskonzept
Die Hybriden sollen für eine ganz einfach gehaltene Betrachtung doppelt, sowohl als Verbrenner als auch als Elektroauto gezählt werden:
2978 konventionelle Antriebe mit Verbrennungsmotor
Es liegen keine öffentlich verfügbaren Informationen der Reederei vor; offenbar wurde ausschließlich direkt mit Presse und Coast Guard kommuniziert.
Das einzige, was die These mit dem Elektroauto-Deck stützen könnte, wäre, dass das Schiff gezielt auf Lücke beladen worden sein könnte, um die Elektroautos zu isolieren. Ich würde tatsächlich erwarten, dass von unten nach oben beladen wird, die schweren Elektroautos zuunterst, und dann auch keine Lücken gelassen werden, um den Schwerpunkt niedrig zu halten.
Will man der neuen Entwicklung folgen, dass Hybride als Elektroautos zählen, waren auf den entsprechenden Decks (nicht nur auf einem) hunderte Hybride mit Verbrennungsmotoren verladen und die These vom Elektroauto-Deck ist in sich nicht schlüssig.
Ein Defekt am Schiff, oder Fahrlässigkeit, sind genauso denkbar wie ein Defekt an einem der Autos.
Anders als im Fall der Fremantle Highway, wo die am Brand schuldigen Elektroautos alle unbeschädigt von Bord gekommen sind, liegen alle Beweisstücke diesmal in kaum erreichbaren 5000 Metern Tiefe am Grund des Pazifik.
Martin Schmitt ist in den 1990er Jahren nach Ausbildung und Berufstätigkeit als gelernter Speditionskaufmann in die IT gewechselt, hält sich also selbstbewusst für einen Experten in Logistikfragen.
Dieses Posting wurde – wie alle anderen auf diesem Blog – ohne die Unterstützung eines großen Sprachmodells (im Volksmund “künstliche Intelligenz”) verfasst.
--argfile behaves differently depending on the number of JSON objects in the file. If it the file contains 1 JSON object, it is returned as a JSON object. If I create a JSON file that contains 2 JSON objects, they are converted to a list of objects:
--slurpfile treats all JSON objects the same and if the file contains a single JSON object, returns a list of JSON objects containing a single entry. Hence the added [0] from the TL;DR section.
One might argue that the removal of --argfile could have come following a clear deprecation notice instead of semi-permanently (first appearance in Debian 9/Stretch) advising against its use and then removing it all of a sudden. However, as far as I am concerned, the issue was detected in earliest Debian 13 compatibility testing within days after the freeze, I immediately knew what was cooking, the migration to --slurpfile was trivial, and it can also be deployed retroactively on all older systems.
Not the first appearance of systemd-run in this category, and probably not the last. Here’s how to hand a task to systemd-run in order to be retried a number of times.
My bro math for interval calculation goes like this:
RestartSec = Time to wait between end of a failed attempt and start of the next attempt
RuntimeMaxSec = Allowed time for each attempt
StartLimitBurst = Number of attempts to make
StartLimitIntervalSec = (RestartSec + RuntimeMaxSec) x StartLimitBurst x 10
So for a service that shall retry every 5 minutes (RestartSec), 12 times (StartLimitBurst), and shall be timed out after 30 seconds (RuntimeMaxSec):
sudo install -m 0755 /dev/stdin /etc/NetworkManager/dispatcher.d/vpn-up << "Here"
#!/bin/sh
if [ "$2" = "vpn-up" ]; then
ip link set dev "$1" mtu 1392
fi
Here
Caveat: The preview pane inside OBS requires 24 bit color depth.
The ~/.xinitrc sets a language environment, which I use for influencing the date format inside the OBS browser source. The OBS invocation also starts the stream automatically, and ignores uncontrolled shutdowns of OBS, so the stream will autostart after a reboot.
The VNC service will be bound to localhost only, but adding a password won’t hurt and will hardly be noticeable once it’s setup and saved in the VNC client.
x11vnc -storepasswd
Another systemd user-unit takes care of starting x11vnc:
Pipewire Easyeffects with RNNoise on Debian 12 / Bookworm
Gnome Night Light from Sunrise to Sunset, without Location Services
Revisiting ratarmount
Pipewire Easyeffects with RNNoise on Debian 12 / Bookworm
RNNoise for removing background sound on your microphone is not included in Debian 12, due to licensing issues around its training data. The least painful way to work around this is to install the Easyeffects Flatpak instead of the packaged easyeffects:
Ich habe einige Monate damit rumgemacht, dass das Konglomerat Telegraf/Prometheus/Grafana von ziemlich starken Abhängigkeiten bei der Startreihenfolge der beteiligten Systeme geplagt ist. Meine Server rebooten alle einmal pro Woche automatisch innerhalb eines gewissen Zeitfensters und seit Grafana musste ich so alle 2-3 Wochen manuell eingreifen und Services neustarten, da insbesondere Telegraf davon ausgeht, dass Schnittstellen, auf die es selbst zugreift, beim eigenen Start erreichbar sein müssen. (Siehe auch: Fallacies of distributed computing.)
Die Frage war also, wie sieht die einfachste Lösung aus, um einen gegebenen Service 60 Minuten nach seinem Start noch einmal automatisch durchzustarten (mit sporadischen Lücken in den Daten kann ich am frühen Sonntagmorgen leben).
Timer und dedizierte Service-Units zu verteilen schien mir zu aufwändig, und ich habe unangenehm lange gegrübelt, wie die simpelste Lösung aussehen könnte, die einfach per systemctl edit foo.service (oder per anderweitig verteiltem systemd drop-in, ymmv) in die betreffende Unit eingebracht werden kann.
Angekommen bin ich schließlich bei dieser Bandwurmzeile:
systemd-run instanziiert einen transienten timer und service, der in einer Stunde systemctl restart ausführen wird. %N wird dabei durch den Namen der übergeordneten Unit (hier also: telegraf) ersetzt.
Der Name des transienten timer und service wird über die Option --unit vorgegeben um im vorherigen Schritt (eins weiter links) vorhersagbar zu sein.
systemd-run wird nur dann ausgeführt, wenn nicht bereits eine Unit aktiv ist, die den vorgegebenen Namen hat, den die transiente Unit bekommen würde, wenn sie noch auszuführen wäre.
Das ganze ist als Shell-Aufruf gewrappt, um den || – Operator zu haben.
ExecStartPost=+ führt als root aus, obwohl die übergeordnete Unit ihre Befehle unprivilegiert ausführt.
ExecStartPost=- ignoriert den Fehler aus dem Shell-Einzeiler, wenn die Unit bereits aktiv war. Es könnte ersatzweise auch ; true ans Ende des Einzeilers geschrieben werden.
Im vorigen Jahr habe ich über mein kleines EDC-Toolkit geschrieben, das ich auf Verdacht schnappen kann, wenn ich aus der Haustür gehe, um viele Kleinigkeiten um Haus und Hof direkt an Ort und Stelle erledigen zu können. Ein zweites, fast identisches Kit mit kleineren Änderungen begleitet mich zwischenzeitlich auf allen Reisen.
Der 100 cm Gliedermaßstab tut immer noch den Job, bis mir ein sehr kompaktes aber ernstzunehmendes Bandmaß für unter 10 Euro in die Hände fällt.
Bleistift und Spudger warteten einfach viel zu spitz in der Tasche darauf, sich unter die Nägel wühlender Finger zu bohren. Der Bleistift wurde durch einen dünnen Edding 400 ersetzt, der Spudger durch ein selbstkonstruiertes Spudger-Bit.
Die Schraubenlehre ist nicht mehr im Kit und stationär im Bereich von Werkbank und Basteltisch besser aufgehoben.
Abt. Schrauben
Die Mini-Ratsche mit 1/4-Zoll-Sechskantabtrieb und Adapter auf 1/4-Zoll-Vierkantabtrieb. In Kit Nr. 2 handelt es sich um eine Variante von KWB, gegenüber der Wera-Ratsche wirklich haushohe Preis-Leistungs-Siegerin, die mir 2023 noch nicht bekannt war.
Der Stubby-Bithalter von Wiha ist in der Variante ohne Doppelbits (rechts) eine Idee angenehmer, da die Bits magnetisch gehalten werden. Die Ratsche muss dann auch nicht mehr aufs Durchstecken der zweiseitigen Bits ausgelegt sein.
Der unauffälligste Bonuscontent im Kit ist ein PH0-Bit mit 1/4-Zoll-Antrieb, das im Stubby zwar etwas ungelenk aussieht, aber im Bedarfsfall einfach deutlich besser ist als kein PH0-Bit.
Ich habe nicht vor, den Doppelbit-Stubby auszusortieren, bin aber zwischenzeitlich der Meinung, dass die Doppelbits zu wenig Platz sparen um die Fragen zu beantworten, die sie aufwerfen. Die Bitverlängerung, um normale Bits ohne übertriebenes Gefummel einzusetzen, neutralisiert den Gewichtsvorteil der Doppelbits. Es bringt einfach nichts.
Abt. Sechskant
Der 100er Rollgabelschlüssel kann Schrauben bis 15 mm Schlüsselweite greifen. Der Rollstuhl meiner Liebsten ist damit nicht versorgt, allerdings benötigt dieser gerade an den dicken Schrauben einen Drehmomentschlüssel mit recht hohem Anzugsmoment.
Der Rollgabelschlüssel kann ohne großes Drama auf einen 150er upgegradet werden; abgeraten wird aber weiterhin vom automatischen Rollgabelschlüssel “Wera Joker 6004“, dem es an Vielseitigkeit fehlt.
Der 1/4-Zoll-Vierkantadapter für die Ratsche war zu schade, um ihn nicht zu nutzen. Beide Kits enthalten eine kleine selbstkonstruierte Box mit 8, 10 und 13 mm Stecknüssen. Für die Nüsse aus der KWB-Ratschenbox mit ihrem Vielzahn-Profil wurde das Modell um 15% vergrößert.
TL;DR: Das KWB-Kit “Bits and Sockets” inclusive Ratsche zusammen mit dem Wiha Stubby mit Torx-Sortiment bringt es für 25 Euro mit weniger glitschiger Ratsche und griffigerem Schraubendreher in etwa auf den Funktionsumfang eines Wera Toolcheck, der aber mindestens das doppelte kostet. Aber Achtung, nur der Toolcheck enthält 7er und 5,5er-Stecknüsse für M4- und M3-Schrauben.
McGyver-Gedächtnis-Abt.
120er Kombizange – Hier tut es wirklich die Baumarktzange für wenige Euro.
Das Konzept “Gaffa auf Pappdeckel umgerollt” ist bekannt, wird von mir aber aus verschiedenen Gründen abgelehnt.
Seit ich im Außeneinsatz eine halbe Rolle Klebeband zum provisorischen Seil verdrehen musste, um etwas festzubinden, habe ich ein Stück Paracord 550 dabei.
Die Influencer-Arbeitsleuchte von Brennenstuhl habe ich nur einmal und sie hat sowohl in den dunklen Hallen des Chaos Communication Congress als auch in einer Ferienwohnung ohne Nachttischlampe(?!?) extrem gute Dienste geleistet. Dazu passend, der Ständer zum selbst drucken.
Ein paar Milliliter reines Isopropanol sind spannender als ranzelndes Desinfektionsmittel aus Pandemiebeständen, und eignen sich genauso gut, um Klebe- und Eddingrückstände zu entfernen.
Abt. Zukunftsmusik
Was fehlt, aber überhaupt nicht ins Konzept passt, ist ein Hammer. Wenn der Drang zu groß wird, unvorbereitet auf Dinge einzuschlagen, könnte irgendwann eine schwere Kombizange im Stil amerikanischer Lineman’s Pliers in die Bresche springen.
Leider, und das ist echt ein großes Leider, fehlt immer noch eine ganz einfache Schieblehre. Ich hätte sie hier und da gern gehabt, kam dann aber auch Pi mal Daumen zurecht. Vielleicht habe ich ja Glück und dieser Cliffhanger kann bis zum nächsten Review aufgelöst werden.
What goes up, must come down. Ask any system administrator.
