starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[PR #1112] [MERGED] fix(wm): add read timeout to command socket #1207

New Issue
Closed
opened 2026-01-05 14:54:28 +01:00 by adam · 0 comments
adam commented 2026-01-05 14:54:28 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/LGUG2Z/komorebi/pull/1112
Author: @alex-ds13
Created: 11/11/2024
Status: ✅ Merged
Merged: 11/11/2024
Merged by: @LGUG2Z

Base: master ← Head: fix/commands-stopping

📝 Commits (1)

  • 544ed03 fix(wm): add read timeout to command socket

📊 Changes

1 file changed (+13 additions, -4 deletions)

View changed files

📝 komorebi/src/process_command.rs (+13 -4)

📄 Description

After investigating further the issue where commands would randomly stop working, we've noticed that the issue seems to be that somehow the listening thread gets stuck reading the unix socket, as in it continuously tries to read a socket on a connection that is not sending anything anymore. The result would be that komorebi would no longer be able to receive commands until it was restarted.

This fix adds a read timeout of 1s and it spawns a new thread to handle the stream reading and process of cmds. So in case this happens again, that specific processing thread will only be stuck for 1s but the rest of komorebi will never get stuck and should keep working normally.

@LGUG2Z I still don't know the cause of this issue, but this fix should work no matter what is causing it.

I did manage to somewhat be able to reproduce this by simply having a new app that connects to the komorebi socket and does a read_to_string on the socket. What I was expecting was that this new testing app would get stuck trying to read an empty socket forever, but komorebi would still be working fine, however what I saw was that after the new app calls read_to_string the komorebi listener triggers the .incoming() as if some client had written something to the socket which didn't happen, so komorebi will try to read the socket as well and it also gets stuck!

This is I believe what is actually happening, now I don't know how exactly it is happening. Somehow some client is making a read call without anything being written. So I'm not sure how it happens, it must be some combination of timing, CPU usage and the actual USER using some keybinding to call a command at the same time...

By the way, with this fix if I use that testing app mentioned above to try to recreate the issue, komorebi never stops working (doesn't even hang for 1s, I keep spamming focus change commands and it never fails, stops or hang), only the testing app hangs for 1s and then finishes.

No matter what it is, this fix should work. But the only way to know for sure is to put it out there and see if users stop reporting the issue.

I'm sorry it took this long to put this fix up, since it is such a simple fix we could probably have merged this before and would know by now if there were users still reporting the issue or not, but I was really trying to figure out the root cause of the issue, what is causing it...

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/LGUG2Z/komorebi/pull/1112 **Author:** [@alex-ds13](https://github.com/alex-ds13) **Created:** 11/11/2024 **Status:** ✅ Merged **Merged:** 11/11/2024 **Merged by:** [@LGUG2Z](https://github.com/LGUG2Z) **Base:** `master` ← **Head:** `fix/commands-stopping` --- ### 📝 Commits (1) - [`544ed03`](https://github.com/LGUG2Z/komorebi/commit/544ed03d239ae8d0333076bab9f04150abd280ae) fix(wm): add read timeout to command socket ### 📊 Changes **1 file changed** (+13 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `komorebi/src/process_command.rs` (+13 -4) </details> ### 📄 Description After investigating further the issue where commands would randomly stop working, we've noticed that the issue seems to be that somehow the listening thread gets stuck reading the unix socket, as in it continuously tries to read a socket on a connection that is not sending anything anymore. The result would be that komorebi would no longer be able to receive commands until it was restarted. This fix adds a read timeout of 1s and it spawns a new thread to handle the stream reading and process of cmds. So in case this happens again, that specific processing thread will only be stuck for 1s but the rest of komorebi will never get stuck and should keep working normally. @LGUG2Z I still don't know the cause of this issue, but this fix should work no matter what is causing it. I did manage to somewhat be able to reproduce this by simply having a new app that connects to the komorebi socket and does a `read_to_string` on the socket. What I was expecting was that this new testing app would get stuck trying to read an empty socket forever, but komorebi would still be working fine, however what I saw was that after the new app calls `read_to_string` the komorebi listener triggers the `.incoming()` as if some client had written something to the socket which didn't happen, so komorebi will try to read the socket as well and it also gets stuck! This is I believe what is actually happening, now I don't know how exactly it is happening. Somehow some client is making a read call without anything being written. So I'm not sure how it happens, it must be some combination of timing, CPU usage and the actual USER using some keybinding to call a command at the same time... By the way, with this fix if I use that testing app mentioned above to try to recreate the issue, komorebi never stops working (doesn't even hang for 1s, I keep spamming focus change commands and it never fails, stops or hang), only the testing app hangs for 1s and then finishes. No matter what it is, this fix *should* work. But the only way to know for sure is to put it out there and see if users stop reporting the issue. I'm sorry it took this long to put this fix up, since it is such a simple fix we could probably have merged this before and would know by now if there were users still reporting the issue or not, but I was really trying to figure out the root cause of the issue, what is causing it... <!-- Please follow the Conventional Commits specification. If you need to update your PR with changes from `master`, please run `git rebase master`. By opening this PR, you confirm that you have read and understood this project's `CONTRIBUTING.md`. --> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-01-05 14:54:28 +01:00
adam closed this issue 2026-01-05 14:54:28 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#1207
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?