The next Omarchy installs rtkit, so apps stop vanishing silently and audio stops crackling
A missing system service was quietly killing Chrome, Electron apps and SteamVR on x86 Omarchy and starving PipeWire under load. The fix is merged, along with a follow-up that keeps Hyprland safe.
Image: omacom/omarchy PR #16824 (GitHub)
If Chrome, VS Code or the Claude desktop app has ever just disappeared on your Omarchy machine with no error, this one is for you. Pull request #16824 by @emirb, merged on October 28, 2026, installs rtkit on every platform and repairs running sessions so the silent kills stop. It is coming in the next version.
According to the PR, Omarchy on x86 shipped without rtkit, the system service that grants realtime scheduling to user programs that ask for it. It was only listed in the aarch64 package list. Two problems on every x86 install came out of that one gap: apps dying silently, and audio crackling under load.
The silent deaths hit Chrome, Electron apps (Claude, ChatGPT, Codex, VS Code), JetBrains Rider, SteamVR and Playwright’s Chromium. They vanish with no dialog, no core dump and nothing in the journal. The cause, as emirb explains it: without rtkit, apps launched from the desktop end up with a realtime budget of zero, PipeWire turns that into a hard RLIMIT_RTTIME of 0, and the kernel enforces it with SIGKILL, even on a thread that never ran realtime. Apps started from the Super + Space menu and anything that loads PipeWire itself were affected.
The audio side is just as concrete. Without realtime, PipeWire’s audio threads queue behind everything else and miss the sound card’s deadline during builds, games or LLM inference. emirb measured it on two real machines with PipeWire’s xrun counter and a quantum of 128: card dropouts under load went from 111 to 0 on a Dell XPS 16 and from 92 to 0 on an i5-12600K desktop. The worst audio-thread wakeup on the XPS 16 dropped from 12.2 ms to 22 µs.
Simply adding the package would not have been enough. The PR notes that installing rtkit on a running machine can make things worse, because an app that already holds the zero can then be made realtime and killed. So a new omarchy-realtime-repair command, run by a migration during omarchy update, raises those zero budgets before and after installing rtkit and restarts what needs restarting. In emirb’s real upgrade tests, no app was killed, including 15 Chromium processes left open on the XPS 16.
There was one side effect, and it is already handled. With rtkit present, Hyprland 0.57 started getting realtime scheduling too, with a 200 ms cap. @shawnyeager reported in issue #17102 that one slow kernel call on the compositor’s main thread got Hyprland SIGKILLed, with six silent deaths on the first day on a Dell XPS 14 running a dev build.
The fix, pull request #17103 by @shawnyeager, merged by emirb on October 30, 2026, sets HYPRLAND_NO_RT=1 in the default uwsm session settings, so Hyprland runs without realtime as it did before rtkit arrived. PipeWire keeps its realtime. If you want realtime for the compositor anyway, set HYPRLAND_NO_RT=0 in ~/.config/uwsm/env.d/. The PR says the setting goes away once Hyprland fixes the underlying bug upstream.
Both changes landed after the RC2 release candidate was cut late on October 27, 2026 (UTC), so they are not in RC2. Commenting on the issue, emirb said the Hyprland fix would reach the edge channel in about an hour; for everyone else, both fixes are coming in the next version.
