[Bug]: ManagedOOMPreference=avoid in t3code.service puts systemd --user into a 100% CPU loop with uresourced (Fedora/GNOME)

从apps/server/src/cloud/bootService.ts开始，阅读单元模板，尤其是ManagedOOMPreference=avoid设置及其附近的注释。检查模板与已报告的反馈循环以及现有的每个代理作用域之间的关系。完成的标准是，已安装的服务不再触发所述CPU循环，同时保留预期的保护；请在Fedora/GNOME上使用uresourced 0.5.4验证单元行为。

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Fedora 44 Workstation (GNOME), which ships and enables uresourced --user 0.5.4.
2. Install the background service with a build that includes #17662 (any nightly since 2026-10-10, or v0.1.0): t3 service install.
3. Leave it running. At some point (in my case within a day of installing), systemd --user goes to ~100% CPU and stays there.

Expected behavior

The t3code.service unit doesn't cause any ongoing work in the user manager once it's running.

Actual behavior

systemd --user pins a core indefinitely, and uresourced --user sits at ~13–15%. On my machine this has run for about 6 days: the user manager has accumulated 5d18h of CPU time.

The unit template in apps/server/src/cloud/bootService.ts (added in #17662, still on main @ 133f57a832) sets ManagedOOMPreference=avoid, and that sets up a feedback loop with uresourced:

1. Because of ManagedOOMPreference=avoid, systemd sets the user.oomd_avoid xattr on the t3code.service cgroup, and re-applies it whenever the unit's properties change.
2. Each xattr write is an IN_ATTRIB event on the cgroup directory. uresourced watches app.slice cgroups for IN_ATTRIB and responds with SetUnitProperties(t3code.service, CPUWeight=100, IOWeight=100).
3. That property change re-applies the xattr, so step 1 happens again, forever.

Measured on a live system:

• ~2,500 IN_ATTRIB events/sec on app.slice/t3code.service, and zero on any other cgroup in app.slice.
• ~1,900 SetUnitProperties calls/sec from uresourced --user to the user manager, all for t3code.service, all CPUWeight=100 IOWeight=100.

This is a uresourced bug at heart. It was reported in benzea/uresourced#9, where the reporter also had ManagedOOMPreference=avoid on the affected units, and fixed upstream in b9bf446 (2026-09-20, "avoid reconfiguring units with the same value"). That fix isn't in any tagged release, so Fedora's 0.5.4 still loops. Until distros pick it up, any T3 service install on Fedora/GNOME is exposed.

Side effect: uresourced keeps resetting the weights to 100, so the unit's CPUWeight=1000 / IOWeight=1000 never actually take effect on these systems.

Suggested fix: drop ManagedOOMPreference=avoid from the unit. The comment above it already notes that oomd ignores it on typical distros (oomd watches user-1000.slice, which root owns), and per #17662 the per-agent scopes are what actually protect the server. An alternative is to only emit it when the monitored cgroup is user-owned.

Impact

Major degradation or frequent failure

Version or commit

v0.1.0 (also every nightly since 0.0.46-nightly.20261010); unit template unchanged on main @ 133f57a832

Environment

Fedora 44 (kernel 7.2.5-200.fc44), systemd 259.9-1.fc44, uresourced 0.5.4-5.fc44, GNOME on Wayland

Logs or stack traces

$ top -b -n1 -p 1725,1058839
   1725 brian  20   0   28512  15256  10112 R  99.7   0.0   5d+18h systemd
1058839 brian  20   0  382620   9360   8648 S  14.9   0.0    18,40 uresourced

$ getfattr -d -m - /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/t3code.service
user.oomd_avoid="1"

$ busctl --user monitor (3s, counted)
   5665 Member=SetUnitProperties   # all from :1.21220 = /usr/libexec/uresourced --user

  Sender=:1.21220  Destination=:1.1  Path=/org/freedesktop/systemd1  Interface=org.freedesktop.systemd1.Manager  Member=SetUnitProperties
  MESSAGE "sba(sv)" {
          STRING "t3code.service";
          BOOLEAN true;
          ARRAY "(sv)" {
                  STRUCT "sv" { STRING "CPUWeight"; VARIANT "t" { UINT64 100; }; };
                  STRUCT "sv" { STRING "IOWeight";  VARIANT "t" { UINT64 100; }; };
          };
  };

# inotify IN_ATTRIB on app.slice for 2s
{'t3code.service': 5088}

Workaround

Either of:

• Override the setting with a drop-in, then systemctl --user daemon-reload:

  # ~/.config/systemd/user/t3code.service.d/no-oomd-avoid.conf
  [Service]
  ManagedOOMPreference=none
  

• Or disable uresourced for the user: systemctl --user mask --now uresourced.

If the user manager is already wedged, systemctl --user daemon-reexec breaks the loop without stopping running services (from uresourced#9).