[BUG] - CPU usage problem

[SpeeDFireCZE]

Issue Checklist

• Includes repro steps that result in the bug occurring
• Searched for existing issues
• Filled out the below sections
• Does not relate to hosting (server configuration, reverse proxy, Cloudflare, etc.)
  • Connection issues are likely due to something in between the browser/agent and the ControlR backend app, not the app itself.
  • Please go to the Discussions section for help with hosting setups.

Describe the bug

When the remotely and controlir agents are both installed on a Linux server (Ubuntu 22.04.5 LTS), the controlir will consume more and more CPU. In my case, it got stuck at 15% CPU usage and was permanently stuck and running process. The remotely agent will have problems too. Normally, it uses a low CPU percentage for checks (about 2% at a time), but when the controlir agent is installed, it will consume more CPU (in my case, 70% for checks).
Together, they will consume almost all of the CPU.

After a fresh install, the controlir agent works as expected, but after some time it gets stuck.

To Reproduce

Steps to reproduce the behavior:

1. Install remotely agent + ControlIR agent
2. wait some time
3. check cpu usage
4. See problem

Client Info

Agent Version: 0.25.15.0
Agent OS: Linux Ubuntu 22.04.5 LTS
Language/Locale of Agent OS: en

Server Info (if self-hosting)

Server OS: Ubuntu 22.04.5 LTS
Language/Locale of Server OS: en
Docker image tag: latest

Other relevant info:

Logs

controlir.log

This is Agent log and it still recreating login screen client

[bitbound]

Unfortunately, I'm not able to repro either of these issues. I have the ControlR agent installed on a few different Linux distros: Fedora 44, Kubuntu 26.04, Mint, Ubuntu 24.04. Fedora and Kubuntu run 24/7, and Kubuntu has 3 different ControlR agents on it. I haven't seen this issue on any of them.

The launching of the desktop client definitely needs an exponential back-off, so I'll add that. I'll also add those log entries to the deduping mechanism like the others in that code path.

Hopefully the answer to the below questions can help narrow it down.

Question 1:
Which tool were you using that reported 70% utilization (e.g. htop, System Monitor GUI, etc.)? I ask because tools report utilization differently. Some will show % of a single core, while others will show % of all cores.

Question 2:
I'm sorry to ask, but are you sure it was reporting 70% and not 0.70%? Again, sorry to ask, but I can see that being mistaken in the System Monitor GUI, especially if there aren't any processes showing that are > 1%:

Question 3:
Is the agent running on Ubuntu Server or Ubuntu Desktop?

Question 4:
Can you describe the hardware environment a little more?

• Bare metal vs Hyper-V/VirtualBox/etc.
• Display attached, HDMI dongle, virtual display, etc.
• RAM and CPU.

Question 5:
Is the machine actually sitting at the greeter/login screen in this case? (Trying to determine if it's misreading its environment.)

Question 6:

The DesktopClient appears to be crashing instantly after launching, and it's no doubt due to the missing xauth for the greeter.

If you look further back in the agent logs, do you see an entry like this:

2026-06-30 14:05:20.836 -07:00 [INF] Login screen detected. Type: X11, Display: :0, XAuth: /run/lightdm/root/:0, DM: lightdm { SourceContext: "ControlR.Agent.Common.Services.Linux.DesktopClientWatcherLinux", ThreadId: 5 }

If so, can you show me that and the surrounding entries?

Question 7:
Do you have any logs under /var/log/controlr/{instance_id or "default"}/ControlR.DesktopClient? (These would also show in the Remote Logs page under "DesktopClient Logs (root)".)

If so, what do those have in them?

[mattish91]

Im running both ControlR and Remotely on almost all my systems, both Linux and Windows, i have never seen this issue.

I probably shouldn't be running both on the same machine, but being able to schedule scripts and running scripts on-demand is sort of critical which makes me not able to fully make the switch just yet.

I have noticed that the remote controlling of ControlR is much more reliable and stable, being able to pick up after a computer is rebooted or lost connection for a few minutes isn't such a big issue as with remotely having to start a new session when the device goes live, and at some points needing to reboot the machine inorder for it to connect back up again.

Never noticed any sort of impact on cpu/ram or disk with any of them. Most machines are also connected to a monitoring system alerting me of performance issues or reliability issues.

[SpeeDFireCZE]

Found it.
My server is headless, yet ControlR kept detecting a screen and looping on it. The cause was Neko (https://github.com/m1k1o/neko), a virtual browser that I was running in a container. Neko spins up its own virtual X screen, which shows up under pgrep -a Xorg
so ControlR saw a 'display' and tried to connect to it, even though it wasn't a real or usable screen. This triggered a loop of attempts to connect to the screen, which probably resulted in a CPU usage peak after some time. After stopping the Neko container, the screen detection stopped and the log is clean. ControlR now correctly reports the server as headless.

PS.: My server isn't very powerful. I use an Intel NUC with an 11th generation i3 processor, so I can see every CPU spike in my graph. I think that's why I detected it. If my CPU was stronger, it's possible that I wouldn't have detected it at all.

Log now shows:

instead of

[bitbound]

@SpeeDFireCZE Thanks for the follow-up! That explains why the Xauth wasn't present.

This was still a worthwhile bug. I'll add a guard for the missing xauth, add a backoff/cooldown for this code path, and dedupe the logs.