One line in the Omarchy 4.5 notes, “Startup no longer stalls on binfmt registration,” hides a nice speedup. Omarchy Central dug into the two systemd changes from DHH behind it.
What changed
- binfmt mount pulled in explicitly. systemd-binfmt.service (which registers QEMU handlers and other foreign binary formats) was ordered after the binfmt mount but never pulled it in, so it waited almost a second on an automount. A pair of drop-ins fixes that. The service went from 992 ms to 13 ms.
- Less mount-event throttling. systemd’s mount monitor normally takes five notifications per second. The second PR raises that to 30.
Over ten VM boots, median userspace startup went from 2.413 s to 1.501 s with the first fix and 0.737 s with both. All 31 QEMU handlers still registered and an ARM64 Alpine container still ran.
The fine print
These are VM numbers, and the PR says so. Under a synthetic 1,000-mount stress test, PID 1 CPU went from about 5.3% to 15.5% of a core, and the tuning knob is flagged for a recheck on systemd upgrades. The settings ship through Omarchy’s normal config path, so on 4.5 you get them on your next boot.
My take
I love this kind of work: measure, find the stall, fix it, and be honest about the tradeoff. I’ll check my own boot with systemd-analyze and see what my hardware says.
God Bless, and Happy hacking!
