[GH-ISSUE #1936] Barrier server sometimes gets stuck at 100% cpu, strace shows write(4, "\1\0\0\0\0\0\0\0", 8) #1412

Open
opened 2026-05-05 07:49:04 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @victortrac on GitHub (May 7, 2023).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1936

What happened?

I run barrier server from linux and a client on MacOS. Everything works great, but every day or two, the barrier process on my linux machine shows 100% CPU usage (as seen via top) and does not work as expected - my mouse does not leave my linux server's screen edge to the macos desktop. strace shows this, with the write syscall repeating the same 4-5 lines every few minutes:

> sudo strace -p 626179
strace: Process 626179 attached

write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8

lsof shows file descriptor 4 like this:

> lsof -p 626179 | grep "4u"
barrier 626179 victor    4u  a_inode               0,14        0     2097 [eventfd:120]
barrier 626179 victor   14u     unix 0x00000000f08c4510      0t0 38894295 type=STREAM (CONNECTED)

Version

v2.4.0

Git commit hash (if applicable)

No response

If applicable, where did you install Barrier from?

archlinux community repo:

community/barrier 2.4.0-2 (353.6 KiB 1.3 MiB) (Installed)
    Open-source KVM software based on Synergy (GUI)

What OSes are you seeing the problem on? (Check all that apply)

Linux

What OS versions are you using?

Linux h1 6.2.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 20 Apr 2023 16:11:55 +0000 x86_64 GNU/Linux

Relevant log output

> sudo strace -p 626179
strace: Process 626179 attached

write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8


### Any other information

_No response_
Originally created by @victortrac on GitHub (May 7, 2023). Original GitHub issue: https://github.com/debauchee/barrier/issues/1936 ### What happened? I run barrier server from linux and a client on MacOS. Everything works great, but every day or two, the barrier process on my linux machine shows 100% CPU usage (as seen via top) and does not work as expected - my mouse does not leave my linux server's screen edge to the macos desktop. strace shows this, with the write syscall repeating the same 4-5 lines every few minutes: ``` > sudo strace -p 626179 strace: Process 626179 attached write(4, "\1\0\0\0\0\0\0\0", 8) = 8 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 ``` lsof shows file descriptor 4 like this: ``` > lsof -p 626179 | grep "4u" barrier 626179 victor 4u a_inode 0,14 0 2097 [eventfd:120] barrier 626179 victor 14u unix 0x00000000f08c4510 0t0 38894295 type=STREAM (CONNECTED) ``` ### Version v2.4.0 ### Git commit hash (if applicable) _No response_ ### If applicable, where did you install Barrier from? archlinux community repo: ``` community/barrier 2.4.0-2 (353.6 KiB 1.3 MiB) (Installed) Open-source KVM software based on Synergy (GUI) ``` ### What OSes are you seeing the problem on? (Check all that apply) Linux ### What OS versions are you using? ``` Linux h1 6.2.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 20 Apr 2023 16:11:55 +0000 x86_64 GNU/Linux ``` ### Relevant log output ```shell > sudo strace -p 626179 strace: Process 626179 attached write(4, "\1\0\0\0\0\0\0\0", 8) = 8 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 ``` ``` ### Any other information _No response_
Author
Owner

@m10d commented on GitHub (May 11, 2023):

Is the macOS machine a laptop? Are you taking, rebooting, or otherwise removing it from the server's network?

I often (always?) get a pegged CPU and non-functional mouse sharing (mouse 'stuck' on main dev box) when the client machine is taken off the network. In my case, server is ubuntu20.04, client is win10. For example, I just rebooted the windows client - and noticed barrier pegging one core. When the windows box comes back online, barrier functionality is not restored.

running systemctl --user restart barrier-kvm.service on the server (no action on the client other than barrier client auto-runs on boot) does restore mouse-sharing functionality.

In my case as best I can tell, this spinning bug has only been exercised by taking the machine off the network. I came to submit a bug - but it's not looking like this wonderful project is not actively maintained :(

In my strace, I see an infinite loop around reading from a socket (which sounds plausible given my reproduction, possibly not for yours)

recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241  t\4\0\240\4\25\2\0\0M\v\246\32\200\334h\313 \317h\35\1\0\0\0\231B.\314", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
futex(0x56431318e8d0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fff1d68cf20, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fff1d68cf20, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7fff1d68cf20, FUTEX_WAKE_PRIVATE, 1) = 0
...
<!-- gh-comment-id:1543281126 --> @m10d commented on GitHub (May 11, 2023): Is the macOS machine a laptop? Are you taking, rebooting, or otherwise removing it from the server's network? I often (always?) get a pegged CPU and non-functional mouse sharing (mouse 'stuck' on main dev box) when the client machine is taken off the network. In my case, server is ubuntu20.04, client is win10. For example, I just rebooted the windows client - and noticed barrier pegging one core. When the windows box comes back online, `barrier` functionality is not restored. running `systemctl --user restart barrier-kvm.service` on the server (no action on the client other than barrier client auto-runs on boot) **does** restore mouse-sharing functionality. In my case as best I can tell, this spinning bug has only been exercised by taking the machine off the network. I came to submit a bug - but it's not looking like this wonderful project is not actively maintained :( In my `strace`, I see an infinite loop around reading from a socket (which sounds plausible given my reproduction, possibly not for yours) ``` recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241 t\4\0\240\4\25\2\0\0M\v\246\32\200\334h\313 \317h\35\1\0\0\0\231B.\314", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) futex(0x56431318e8d0, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7fff1d68cf20, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7fff1d68cf20, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x7fff1d68cf20, FUTEX_WAKE_PRIVATE, 1) = 0 ... ```
Author
Owner

@victortrac commented on GitHub (May 15, 2023):

@m10d Yup, the macOS machine is a mostly stationary laptop. I suppose the network could blip, but it's not being actively taken off the network for this issue to happen.

Based on your strace, I think you are experiencing a different problem.

<!-- gh-comment-id:1548612331 --> @victortrac commented on GitHub (May 15, 2023): @m10d Yup, the macOS machine is a mostly stationary laptop. I suppose the network could blip, but it's not being actively taken off the network for this issue to happen. Based on your strace, I think you are experiencing a different problem.
Author
Owner

@ylluminate commented on GitHub (May 31, 2023):

AFAIK, the project has moved to: https://github.com/input-leap/input-leap

<!-- gh-comment-id:1570692835 --> @ylluminate commented on GitHub (May 31, 2023): AFAIK, the project has moved to: https://github.com/input-leap/input-leap
Author
Owner

@m10d commented on GitHub (Sep 30, 2023):

AFAIK, the project has moved to: https://github.com/input-leap/input-leap

Note for future readers: hopefully soon ^ but input-leap is not quite ready yet.

I was able to build linux trivially; but after installing and running it on my main/dev box I found:

  • no binaries released for windows
  • I was not able to get my existing windows tablet running barrier connected to the new input-leap install on my dev box.

Crossing fingers for their 3.0 release!

<!-- gh-comment-id:1741879952 --> @m10d commented on GitHub (Sep 30, 2023): > AFAIK, the project has moved to: https://github.com/input-leap/input-leap Note for future readers: hopefully soon ^ but input-leap is [not quite](https://github.com/input-leap/input-leap/discussions/1696) ready [yet](https://github.com/input-leap/input-leap/pull/1697). I was able to build linux trivially; but after installing and running it on my main/dev box I found: - no binaries released for windows - I was not able to get my existing windows tablet running barrier connected to the new input-leap install on my dev box. Crossing fingers for their 3.0 release!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#1412
No description provided.