github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #1454] Ubuntu20 server, windows 10 client, keyboard and mouse failure when client shut down #1112

New issue

Open

opened 2026-05-05 07:29:55 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 07:29:55 -06:00

Owner

Originally created by @qq1018408006 on GitHub (Nov 28, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1454

What happened?

When client shut down, cursor varnishing and keyboard failure occur in server. What I can only do is rebooting server. I think it's awful.
Thanks for your reply.

Version

v2.4.0

Git commit hash (if applicable)

No response

If applicable, where did you install Barrier from?

No response

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

Linux, Windows

What OS versions are you using?

V 2.4.0

Relevant log output

There is no log output when rebooted.

Any other information

No response

Originally created by @qq1018408006 on GitHub (Nov 28, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1454 ### What happened? When client shut down, cursor varnishing and keyboard failure occur in server. What I can only do is rebooting server. I think it's awful. Thanks for your reply. ### Version v2.4.0 ### Git commit hash (if applicable) _No response_ ### If applicable, where did you install Barrier from? _No response_ ### What OSes are you seeing the problem on? (Check all that apply) Linux, Windows ### What OS versions are you using? V 2.4.0 ### Relevant log output ```shell There is no log output when rebooted. ``` ### Any other information _No response_

gitea-mirror commented

2026-05-05 07:29:58 -06:00

Author

Owner

@ph27 commented on GitHub (Nov 30, 2021):

I also experience this. It only seems to happen when the mouse was in the Windows 10 client when the shutdown/reboot of the Windows 10 was initiated. Is the Windows client not gracefully disconnecting from barrier? Or is the server not abandoning the client when there is no response from the client?

My server is 2.3.2 from the ubuntu repository, and my client is 2.3.3, downloaded from github.

I will try 2.4.0 on the client and see if that helps anything. I'm not sure how to update the ubuntu 20.04 server's copy further because that is the latest version available in the ubuntu repository.

I also have SSL turned off on the client and server, and check clients every 5000ms on the server. All other settings are defaults.

@ph27 commented on GitHub (Nov 30, 2021): I also experience this. It only seems to happen when the mouse was in the Windows 10 client when the shutdown/reboot of the Windows 10 was initiated. Is the Windows client not gracefully disconnecting from barrier? Or is the server not abandoning the client when there is no response from the client? My server is 2.3.2 from the ubuntu repository, and my client is 2.3.3, downloaded from github. I will try 2.4.0 on the client and see if that helps anything. I'm not sure how to update the ubuntu 20.04 server's copy further because that is the latest version available in the ubuntu repository. I also have SSL turned off on the client and server, and check clients every 5000ms on the server. All other settings are defaults.

gitea-mirror commented

2026-05-05 07:30:00 -06:00

Author

Owner

@ph27 commented on GitHub (Nov 30, 2021):

Just tested after upgrading the client to 2.4.0, and it still happens. I was able to use Ctrl-Alt-F2 on the Ubuntu 20.04 server to kill the barrier server process using the following command as root:
pkill -9 barriers
This allowed me to kill the barrier server and not be forced to reboot my server. It's not a fix, but at least it lets me continue working without rebooting.

@ph27 commented on GitHub (Nov 30, 2021): Just tested after upgrading the client to 2.4.0, and it still happens. I was able to use Ctrl-Alt-F2 on the Ubuntu 20.04 server to kill the barrier server process using the following command as root: `pkill -9 barriers` This allowed me to kill the barrier server and not be forced to reboot my server. It's not a fix, but at least it lets me continue working without rebooting.

gitea-mirror commented

2026-05-05 07:30:01 -06:00

Author

Owner

@bepcyc commented on GitHub (Dec 1, 2021):

The workaround I found is to add a hotkey with a "Switch to screen" action with server screen as a target.
This way I can always go back to my server screen.

@bepcyc commented on GitHub (Dec 1, 2021): The workaround I found is to add a hotkey with a "Switch to screen" action with server screen as a target. This way I can always go back to my server screen.

gitea-mirror commented

2026-05-05 07:30:03 -06:00

Author

Owner

@audioeptesicus commented on GitHub (Dec 3, 2021):

The workaround I found is to add a hotkey with a "Switch to screen" action with server screen as a target. This way I can always go back to my server screen.

I have the same issue as the OP. Where do you have the functionality of the OP?

@audioeptesicus commented on GitHub (Dec 3, 2021): > The workaround I found is to add a hotkey with a "Switch to screen" action with server screen as a target. This way I can always go back to my server screen. I have the same issue as the OP. Where do you have the functionality of the OP?

gitea-mirror commented

2026-05-05 07:30:04 -06:00

Author

Owner

@Melirius commented on GitHub (Jan 17, 2022):

The same issue in my case. Moreover, after pkill -9 barriers solution input get back to the server, but I cannot connect from the client, client log is

[2022-01-17T11:51:25] WARNING: failed to connect to server: Connection was refused
[2022-01-17T11:51:26] NOTE: connecting to '192.168.0.108': 192.168.0.108:24800
[2022-01-17T11:51:26] INFO: OpenSSL 1.0.2l  25 May 2017

Try to use Switch to screen solution after reboot.

@Melirius commented on GitHub (Jan 17, 2022): The same issue in my case. Moreover, after `pkill -9 barriers` solution input get back to the server, but I cannot connect from the client, client log is ``` [2022-01-17T11:51:25] WARNING: failed to connect to server: Connection was refused [2022-01-17T11:51:26] NOTE: connecting to '192.168.0.108': 192.168.0.108:24800 [2022-01-17T11:51:26] INFO: OpenSSL 1.0.2l 25 May 2017 ``` Try to use `Switch to screen` solution after reboot.