sworkstyle consuming all CPU after switching to i3

[zauster]

Hey,

I guess this is a minor problem, nevertheless I think it is worthwhile reporting: Occasionally I start sway (with sworkstyle running), but then (have to) switch to i3 for some reason. In this situation, sworkstyle keeps running in i3 and keeps consuming 100% of CPU (which is not that surprising in an i3 session, but still annoying) and the process has to be killed.

My expectation was that sworkstyle would terrminate once the sway session is closed.

[Lyr-7D1h]

Not sure what you use to switch wm, but if you fully exit sway it should close all programs inside it including that ones that started with exec. Also not really a sworkstyle problem I think more with the general setup.

[Lyr-7D1h]

Mabye you're also running multiple sworkstyle sessions, that's why it's running with 100%?

[zauster]

Hi,

I switch WMs by closing all programs, exit sway via the swaynag keybinding and then login to i3 via the display manager.
So sworkstyle should be closed as all other programs started at login (such as waybar, dropbox, and so on).

There is only one instance of sworkstyle running, which is consuming 100%.

I start sworkstyle as shown in the README:

exec sworkstyle &> ~/.cache/sworkstyle.log

[Lyr-7D1h]

Can you share output of sworkstyle --log-level=debug

[zauster]

Sure, see here. (## are comments).

   1   │ 2021-07-20 21:33:54,116 DEBUG [sworkstyle] Subscribing to window events
...
  12   │ 2021-07-20 21:35:03,944 DEBUG [sworkstyle] rename workspace "3:  " to "3"
  13   │ 2021-07-20 21:35:08,490 DEBUG [sworkstyle] rename workspace "2:  " to "2"
  14   │ 2021-07-20 21:35:14,281 DEBUG [sworkstyle] rename workspace "1:  " to "1" ## logout and re-login now
  15   │ 2021-07-20 21:35:17,093 DEBUG [sworkstyle] rename workspace "1" to "1:  " ## logged in i3

and nothing afterwards. Line 15 is the first and last line logged in i3, no matter what I open/close, nothing will be logged anymore in sworkstyle.log.

Furthermore, when starting with sway, I find two processes with ps aux:

myuser      783  0.1  0.0   7256  2908 ?        S    21:15   0:00 /bin/sh -c sworkstyle &> ~/.cache/sworkstyle.log
myuser      788  0.1  0.0 750412  3512 ?        Sl   21:15   0:00 sworkstyle  ## 100% CPU

where the second process is the one using 100% CPU in i3.

Does this info help?

[Lyr-7D1h]

Yeah so it makes sense that it will be 100% due to the two processes fighting each other on renaming workspaces.

When you use the latest version of sworkstyle it will actually check for other running instances. This will ensure that there always is only one running instance.

Might want to use the latest version and see if the issue persists.

[zauster]

I am on arch and I am using sworkstyle 1.1.0-1 from the AUR, which is (I think) the latest version, right? So this occurs also with the latest version.

[zauster]

Also, one or two processes does not really matter, if they don't exit when I exit sway, no?

[Lyr-7D1h]

When running one instance can you check if /tmp/sworkstyle.lock exists? Does it start when you open a second instance? Two processes does matter due to high cpu usage when there are multiple instances. I'll have to look into it keep running after closing sway.

[zauster]

Yes, the lockfile does exist (it's empty though). When I manually try to start another sworkstyle process, it errors out with stating that 'Sworkstyle already running'.

[dpgraham4401]

First off, this package is great and thanks for all your hard work!

I'm experiencing similar behavior as @zauster but without i3 (exit sway then log back into a sway session). The workspace icons no longer show up and sworkstyle is consuming ~100% of the CPU usage.

Just wanted to share before I forget, I will try to find time to dig deeper this week.

[dpgraham4401]

So this happens after logging out (back to gnome display manager) and logging back in. Regardless of whether you starting an i3, gnome session, etc. etc.

After logging back in, the icons no longer appear and sworkstyle is running rampant on the cpu

[maricn]

I get in this situation if wayland crashes and I restart it. There's one process clipping the CPU. I'm starting it with exec sleep 3 && sworkstyle & (the sleep part is just to deprioritize the process startup, shouldn't affect the termination afaik).

Actually that's not the only process stuck at 100%, my ActivityWatch also gets there, and it might be the same problem, because it always manifests the same for both of them. ActivityWatch/aw-watcher-window-wayland#9

[joanbm]

I think I may know what's going on... I noticed as well that sworkstyle keeps running after quitting Sway, you can easily see this by running

user@foo$ swaymsg 'exec --no-startup-id sworkstyle'
user@foo$ swaymsg exit

Then logging on another TTY and running top will show sworkstyle still running at 100% CPU usage.

I think the problem is that when the connection to the Sway IPC is broken, the loop here turns into an infinite loop:

swayest_workstyle/src/main.rs

Line 143 in da48e5e

while let Some(event) = events.next().await {

To fix it, it should be enough to add some error handling like so:

diff --git a/src/main.rs b/src/main.rs
index 64a9740..d79ea9e 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -8,7 +8,7 @@ use args::Args;
 use async_std::prelude::StreamExt;
 use config::Config;
 use fslock::LockFile;
-use log::{debug, error};
+use log::{debug, error, warn};
 use simple_logger::SimpleLogger;
 use swayipc_async::{Connection, EventType, Node, NodeType};
 
@@ -145,6 +145,9 @@ async fn subscribe_to_window_events(mut config: Config) -> Result<(), Box<dyn Er
             if let Err(e) = update_workspaces(&mut con, &mut config).await {
                 error!("Could not update workspace name: {}", e);
             }
+        } else {
+            warn!("Connection broken, exiting");
+            break;
         }
     }
 

[Lyr-7D1h]

Thanks @joanbm I've implemented your solution I'll try and see if this solves the problem.

[Lyr-7D1h]

@joanbm it seems it solves the problem! Big thanks for your help @joanbm !!!!! 💯