Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open Beginner friendly
  • Is something wrong?
#20,931 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
69/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
linux, typescript
Domain
backend, devops

Research direction

Start in apps/server/src/cloud/bootService.ts and read the unit template, especially the ManagedOOMPreference=avoid setting and the nearby comment. Check how the template relates to the reported feedback loop and the existing per-agent scopes. Done means the installed service no longer triggers the described CPU loop while retaining the intended protection; verify the unit behavior on Fedora/GNOME with uresourced 0.5.4.

Written by the indexing model from the issue text.

Description

accepted bug via-triage
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).

Dominant language
TypeScript
Stars
24.8k
Forks
6.4k
Avg merge
2h 58m
Merged PRs (30d)
480

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.