komorebi integration can cause infinitely spawning komorebic.exe instances

[Vernetzt]

I'm honestly not sure if this is a yasb, komorebi, or both problem but I have decided to put this issue here for the time being. Let me know if I should move it or if I can provide any additional information.

Under certain conditions yasb being connected to komorebi can cause an error that will produce new komorebic.exe instances to spawn until a new window is focused by komorebi or yasb is terminated. These komorebic.exe instances will persist until yasb is terminated or each task is ended. This seems to be more common when dealing with windows that have had their window decorations removed but is not limited to such windows.

The easiest most consistent steps to reproduce on my system have been as followed:

1. Run komorebi
2. Run yasb with the komorebi widget enabled
3. Open Notepad.exe on an empty workspace
4. Close Notepad.exe (Don't focus any windows after closing)

Result:

I have tried a decent amount of komorebi revisions to attempt to narrow down this problem but most if not all have given similar results. I have also tried the Nov 19th, Dec 4th, and Dec 5th revisions of yasb as well. This error occurring after closing a window and stopping when a new window is focused by komorebi is the only real consistent factor I have found sadly.

Windows 11 22000.348 Yasb - ae15d7bff8baeb09522dff20be70de6b86d9572a komorebi - 9fd4dbf

komorebi error (continues to repeat with each new komorebic.exe being spawned) the (os error 10061) mentioned in my previous issue seemed to also cause this behavior.

ERROR komorebi::process_command: could not get window title

*yasb log

Starting Yasb
Successfully loaded config file and stylesheet
Unknown property cursor
Created bar 0 on monitor \\.\DISPLAY1
Unknown property cursor
Created bar 1 on monitor \\.\DISPLAY2
Activating listener KomorebiEventListener
Activating listener SystemEventListener
SetWinEventHook Successful. Emitting focused window and waiting for events.
Waiting for Komorebi to subscribe to named pipe yasb
Unknown property cursor
Unknown property cursor
Unknown property cursor
Unknown property cursor
Komorebi connected to named pipe: yasb

[da-rth]

The yasb komorebi event listener executes a background QTimer function which queries komorebi's state every 2 seconds whilst it waits for new window manager events. This shouldn't be an issue, but may have something to do with it.

The only other instance where komorebi's state is queried by yasb is here. The state is retrieved only once immediately after Komorebi has connected to the named pipe. Of course, if komorebi happened to be repeatedly disconnecting and reconnecting to the named pipe, this may result in an execessive amount of state query requests to komorebic.exe.

If this is the case, you would see the following log messages in repeated succesion within yasb.log:

• 'Komorebi has disconnected from the named pipe yasb'
• 'Waiting for Komorebi to subscribe to named pipe yasb'
• 'Komorebi connected to named pipe: yasb'

@LGUG2Z may also have some insight as to why this is happening. I will continue to investigate this in the meantime.

[da-rth]

After talking with @LGUG2Z it seems this might be an issue with the state command waiting eternally for a response message from komorebi. If komorebi fails to retrieve the state and send it back, the komorebic state process will deadlock.

Since the state command is executed via pythons subprocess module, when you quit yasb you are also terminating all of the active komorebic state processes.

As a fix, I can specify a max timeout duration for the state commands when executed via subprocess, and then handle the timeout gracefully. This likely would avoid the build-up of komorebic processes.

You may also want to raise an issue on the komorebi repo for tracking/discussing this issue further, as a timeout should probably be implemented on komorebi's end too.

[LGUG2Z]

I've also updated komorebi to always send something in response to a state request, even if it is just an error description. This should avoid komorebic ever hanging on failed state requests: https://github.com/LGUG2Z/komorebi/commit/5e3f1cbb4435bafeff786727a535b59a893aea8c

[Vernetzt]

The change(s) seem to be working well so far with both recent revisions. Still seeing a pretty rare (os error 10061) but the instances no longer pile up with either error, it also seems to process the command along side the error now as well.

Haven't had the time to thoroughly put them through their paces yet but I'll make sure to report back if the behavior reappears. Thanks again for the quick response on both sides.

yasb log

Starting Yasb
Successfully loaded config file and stylesheet
Unknown property cursor
Created bar 0 on monitor \\.\DISPLAY1
Unknown property cursor
Created bar 1 on monitor \\.\DISPLAY2
Activating listener KomorebiEventListener
Activating listener SystemEventListener
SetWinEventHook Successful. Emitting focused window and waiting for events.
Waiting for Komorebi to subscribe to named pipe yasb
Unknown property cursor
Unknown property cursor
Unknown property cursor
Unknown property cursor
Komorebi connected to named pipe: yasb
Unknown property cursor

komorebi log

2021-12-07T02:33:38.246306Z  INFO read_commands:process_command{State}: komorebi::process_command: processed
2021-12-07T02:33:38.246789Z ERROR komorebi::process_command: could not get window title
2021-12-07T02:33:40.256362Z  INFO read_commands:process_command{State}: komorebi::process_command: processed
2021-12-07T02:33:40.256820Z ERROR komorebi::process_command: could not get window title
2021-12-07T02:33:42.250499Z  INFO read_commands:process_command{State}: komorebi::process_command: processed
2021-12-07T02:33:42.250958Z ERROR komorebi::process_command: could not get window title
2021-12-07T02:33:44.244481Z  INFO read_commands:process_command{State}: komorebi::process_command: processed
2021-12-07T02:33:44.244944Z ERROR komorebi::process_command: could not get window title

komorebi log (super rare)

2021-12-07T02:32:00.200344Z  INFO read_commands:process_command{State}: komorebi::process_command: processed
2021-12-07T02:32:02.205350Z ERROR komorebi::process_command: No connection could be made because the target machine actively refused it. (os error 10061)
2021-12-07T02:32:04.199965Z  INFO read_commands:process_command{State}: komorebi::process_command: processed

[da-rth]

Marking as closed since the described behaviour in the initial post appears to be resolved.