You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Antigravity install/sign-in fails on Omarchy ("could not start in this environment", SIGKILL): RLIMIT_RTTIME=0, not T3 Code
#28280
If you're on Omarchy and the Antigravity provider won't work in T3 Code, this is probably the cause. It took me a long debugging session to find, so here's the short version.
Symptoms
Install Antigravity downloads the runtime, then fails with:
The downloaded Antigravity runtime could not start in this environment.
Using a custom ACP executable path doesn't help. Sign in fails too.
In ~/.t3/userdata/logs/server.trace.ndjson you'll see ACP process exited after signal SIGKILL and/or RpcClientDefect: ACP protocol terminated., with no stderr from the runtime.
The same agy_acp_server.par works fine when you run it from a terminal. It answers initialize in about 1 s.
Cause
It isn't T3 Code, and it isn't the runtime. On Omarchy, apps launched from the shell or app launcher inherit RLIMIT_RTTIME = 0. Google's ACP runtime SIGKILLs itself, or stalls, when its real-time budget is zero.
The chain:
rtkit isn't installed, so the xdg-desktop-portal Realtime portal reports RTTimeUSecMax = 0.
PipeWire's libpipewire-module-rt applies that value (soft and hard) to its clients, including Omarchy's shell (quickshell).
Everything launched from the shell inherits 0/0: T3 Code, its server, and the ACP runtime.
Your terminal has unlimited, so every test you run from it passes. That's what makes this so confusing.
Check if this is you
busctl --user get-property org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop \
org.freedesktop.portal.Realtime RTTimeUSecMax
# x 0 <- affected
grep 'realtime timeout' /proc/$(pgrep -x quickshell)/limits
# Max realtime timeout 0 0 us <- affected
You can also compare grep 'realtime timeout' /proc/<t3code pid>/limits with the same line from your shell (/proc/$$/limits).
Fix
This is fixed upstream in Omarchy (repo omacom/omarchy), but the fix wasn't in a release yet as of 4.0.6:
Wait for the Omarchy release that includes both PRs (recommended), then reboot and retry the Antigravity install in T3 Code. You can tell it's landed when /usr/share/omarchy/bin/omarchy-realtime-repair exists and grep HYPRLAND_NO_RT /usr/share/omarchy/default/uwsm/default finds a match.
Do it by hand now:sudo pacman -S rtkit, add export HYPRLAND_NO_RT=1 to a file in ~/.config/uwsm/env.d/, then log out and back in. Don't install rtkit without HYPRLAND_NO_RT if you're on Hyprland 0.57 or newer, or might upgrade to it.
Stopgap (untested): launch T3 Code from a terminal (t3code &). It then inherits the terminal's unlimited limit.
Wrapping the runtime in prlimit --rttime=... won't work. The hard limit is 0, and an unprivileged process can't raise it.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
If you're on Omarchy and the Antigravity provider won't work in T3 Code, this is probably the cause. It took me a long debugging session to find, so here's the short version.
Symptoms
~/.t3/userdata/logs/server.trace.ndjsonyou'll seeACP process exited after signal SIGKILLand/orRpcClientDefect: ACP protocol terminated., with no stderr from the runtime.agy_acp_server.parworks fine when you run it from a terminal. It answersinitializein about 1 s.Cause
It isn't T3 Code, and it isn't the runtime. On Omarchy, apps launched from the shell or app launcher inherit
RLIMIT_RTTIME = 0. Google's ACP runtime SIGKILLs itself, or stalls, when its real-time budget is zero.The chain:
rtkitisn't installed, so the xdg-desktop-portal Realtime portal reportsRTTimeUSecMax = 0.libpipewire-module-rtapplies that value (soft and hard) to its clients, including Omarchy's shell (quickshell).0/0: T3 Code, its server, and the ACP runtime.Your terminal has
unlimited, so every test you run from it passes. That's what makes this so confusing.Check if this is you
You can also compare
grep 'realtime timeout' /proc/<t3code pid>/limitswith the same line from your shell (/proc/$$/limits).Fix
This is fixed upstream in Omarchy (repo
omacom/omarchy), but the fix wasn't in a release yet as of 4.0.6:rtkitto the base packages, plus a repair script.HYPRLAND_NO_RT=1, because once rtkit is installed, Hyprland 0.57 asks for real-time scheduling and can be silently SIGKILLed by the kernel watchdog (Hyprland 0.57 gets silently SIGKILLed now that rtkit is installed on x86 omacom/omarchy#17102, Real-time scheduling. Hyprland dies by SIGKILL when reconnecting HDMI hyprwm/Hyprland#16648).Your options:
/usr/share/omarchy/bin/omarchy-realtime-repairexists andgrep HYPRLAND_NO_RT /usr/share/omarchy/default/uwsm/defaultfinds a match.sudo pacman -S rtkit, addexport HYPRLAND_NO_RT=1to a file in~/.config/uwsm/env.d/, then log out and back in. Don't install rtkit withoutHYPRLAND_NO_RTif you're on Hyprland 0.57 or newer, or might upgrade to it.t3code &). It then inherits the terminal's unlimited limit.Wrapping the runtime in
prlimit --rttime=...won't work. The hard limit is 0, and an unprivileged process can't raise it.Related
All reactions