High CPU and disk write usage on Linux Mint 21.3

[cabottech]

I've noticed high CPU and disk write recently. Not sure exactly when this started, but I noticed my laptop fan spinning up a lot lately and found TrayScale was using a lot of resources.

Screenshot of System Monitor:

When it's doing this, I can't open/maximise it from the systray menu > Show (nothing appears), and when I quit with systray menu > Quit, the systray icon disappears, but the process keeps running.

So I End the process in System Monitor and re launch, and
Then upon reopening, it is much better behaved - Screenshot:

TrayScale Flatpak:

• Version: v0.13.0
• Last updated: July 12, 2024
• Runtime: org.gnome.Platform/x86_64/46

System specs:

• OS: Linux Mint 21.3 x86_64
• Kernel: 6.5.0-44-generic
• DE: Cinnamon 6.0.4
• CPU: Intel i7-9850H (12) @ 2.600GHz
• GPU: NVIDIA GeForce MX150
• GPU: Intel CoffeeLake-H GT2 [UHD Graphics 630]
• Memory: 6165MiB / 31868MiB

[DeedleFake]

That's very strange. Except for when accepting Taildrop files or modifying settings in the preferences page, Trayscale doesn't write to the disk at all. Maybe it's related to #135 and however it's being started is directly attaching stdout/stderr to a file on disk, hence why it's attributing it to the process. That also seemed to be a Mint-specific problem. Can you check to see if a log is filling up somewhere? Also, do you have Taildrop enabled?

[cabottech]

Good idea, I'll check for growing logs next time it happens.

I'm now thinking it may happen when I leave my laptop running for multiple days in the office. I have Suspend and WiFi power saving disabled when plugged-in, but maybe something similar? Or the Cinnamon DE misbehaving?

Also, I haven't enabled Taildrop.

I'll try to reproduce the issue and update here if I find anything. Cheers!

[DeedleFake]

Also, I haven't enabled Taildrop.

Trayscale currently logs an error every time it polls if Taildrop isn't on, which is every five seconds by default. It's something I'm planning on fixing in the near future, but there's a good chance that that's the cause.

Edit: This has now been fixed by #149.

[cabottech]

Thanks! ☕️

I saw the update come through yesterday. I'll let you know if this is an issue in future.

[cabottech]

I've just had this happen again (or at least something similar). I had my laptop running overnight, just locked screen and left it running. This morning when I unlocked, there was a warning about low storage space and computer crippled. So I had to reboot.

I found an enormous log file in my home drive: ~/.xsession-errors.old with this line repeated:

2024/08/23 07:45:57 ERROR get Tailscale status err="get tailscale status: Failed to connect to local Tailscale daemon for /localapi/v0/status; not running? Error: dial unix /var/run/tailscale/tailscaled.sock: connect: no such file or directory"

Here's the first 300 lines of this log, showing where this starts: xsession-errors-old_head_output.txt

This is a bit beyond me, so not sure if this is a Tailscale, Trayscale, Flatpak, or Cinnamon issue?

[DeedleFake]

Hmmm... Looks like Trayscale couldn't find the tailscaled socket and then complained about it and filled up the logs again. Mint is weird that it does that by default.

The most likely cause is that tailscaled crashed or otherwise wasn't running. Does journalctl -du tailscaled.service show anything?

[DeedleFake]

The first lines when it stopped working are

2024/08/22 10:11:44 ERROR get Tailscale status err="get tailscale status: Get \"http://local-tailscaled.sock/localapi/v0/status\": EOF"
2024/08/22 10:11:44 ERROR get Tailscale status err="get tailscale status: Get \"http://local-tailscaled.sock/localapi/v0/status\": read unix @->/run/tailscale/tailscaled.sock: read: connection reset by peer"
2024/08/22 10:11:44 ERROR get Tailscale status err="get tailscale status: Failed to connect to local Tailscale daemon for /localapi/v0/status; not running? Error: dial unix /var/run/tailscale/tailscaled.sock: connect: connection refused"

And then that last line repeats for hundreds of lines. That makes it look to me like Trayscale was connected to the daemon and then suddenly lost the connection, probably because of the daemon crashing. That caused an EOF on some read as the socket suddenly had no data to send. That was followed quickly by a full connection loss, and then repeated failures to reconnect.

[DeedleFake]

So, there is a bug that causes a retry on a failure to get the network status from tailscaled to be instantaneous instead of waiting like when it polls normally, but even if I fix that it'll go from polling repeatedly to once every five seconds by default. I can give it some falloff, but that means that once it comes back up the amount of time that it'll take to notice is quite a while, which is significantly less than ideal.

Unfortunately, this seems to just be a problem with the way Mint has its logging configured and there isn't that much that I can do about it besides manually logging to a file somewhere. You can fix it by adding a &> /dev/null to the end of the Exec line for the autostart config, but that means that if something does break, all the logs will be lost.

[cabottech]

Thanks for looking into this. I'll see how I go, and add the &> /dev/null if this continue to be an issue.

I suspect the connection losses may be related to internet outages which exacerbates things - I've recently been experiencing increased Starlink interruptions and outages.