search

debauchee / barrier

Open-source KVM software
Other
27.2k stars 1.5k forks source link

barriers.exe / barrierc.exe not ending on "Stop" #346

Open Abh15h3k opened 5 years ago

Abh15h3k commented 5 years ago

Operating Systems

Server: Windows 10 / MX Linux 18.3

Client: MX Linux 18.3 / Windows 10

Windows 1809 (OS Build 17763.557)

Barrier Version

2.3.0-snapshot-8e8b38b4

Issue

The issue I'm facing is that in windows when i click stop (after having started as client or server) barriers.exe (when using as server) or barrierc (when using as client) doesn't stop. they keep running in the background.

I have to go to the taskmanager and find barriers.exe or barrierc.exe and kill the process to stop barrier from sharing keyboard n mouse.

I generally use barrier when im simply coding or browsing the web on my laptop (usually linux) and desktop (windows). But when i game on my desktop even after stopping barrier and quiting it from the system tray it would share my keyboard n mouse with my laptop.

noisyshape commented 5 years ago

I've never observed this with the server, but I know this happens with the client. I think the root of the problem is the GUI application not detecting a process started by the service, but I don't know what would cause that or how to reliably reproduce the problem.

allanwmacdonald commented 5 years ago

The barrier application itself (the starting and stopping GUI) also suffers from similar behaviour with a Linux client (Ubuntu 18.04) and Window 7 Server (2.3.0 on both machines).

Case 1:

  1. On linux client machine, open barrier via desktop menu
  2. Close barrier by clicking x in window
  3. ps -ef | grep barrier
  4. barrier process persists.
  5. Remove process by issuing "pkill barrier"

Case 2:

  1. On linux client machine, type the command "barrier" in a terminal
  2. Barrier window appears
  3. Close barrier by clicking x in window.
  4. Process persists in terminal
  5. Must press ctrl-c to return to command prompt.

Case 3:

  1. On windows server, click on the barriers application icon (start menu, desktop, etc) but do not click "start"
  2. Close barrier
  3. open Windows Task Manager, see barrier process still present.
  4. Delete the process in the Task Manager to kill it.

What's interesting is that, starting and stopping the Linux client service (barrierc) works OK while starting and stopping the windows server (barriers) doesn't. In both environments, though, closing the application itself from the gui doesn't actually kill the application and you can end up with multiple instances of the application running without knowing it.

<edited, changing "pressing" to "clicking">

Abh15h3k commented 5 years ago

The barrier application itself (the starting and stopping GUI) also suffers from similar behaviour with a Linux client (Ubuntu 18.04) and Window 7 Server (2.3.0 on both machines).

Case 1:

  1. On linux client machine, open barrier via desktop menu
  2. Close barrier by clicking x in window
  3. ps -ef | grep barrier
  4. barrier process persists.
  5. Remove process by issuing "pkill barrier"

Case 2:

  1. On linux client machine, type the command "barrier" in a terminal
  2. Barrier window appears
  3. Close barrier by clicking x in window.
  4. Process persists in terminal
  5. Must press ctrl-c to return to command prompt.

Case 3:

  1. On windows server, click on the barriers application icon (start menu, desktop, etc) but do not click "start"
  2. Close barrier
  3. open Windows Task Manager, see barrier process still present.
  4. Delete the process in the Task Manager to kill it.

What's interesting is that, starting and stopping the Linux client service (barrierc) works OK while starting and stopping the windows server (barriers) doesn't. In both environments, though, closing the application itself from the gui doesn't actually kill the application and you can end up with multiple instances of the application running without knowing it.

<edited, changing "pressing" to "clicking">

the cases in linux as far as i know is intended. many other software work in the same way. pressing 'x' doesn't kill the proccess it minimizes it ( like minimize to system tray in windows ). when u press 'x' there should be a icon on the top right of your screen ( atleast in ubuntu ). you have to right click that icon and click 'quit' or something.

as for the main issue i was facing in windows. i haven't had the issue for a while. i think just restarting my system got it working correctly. as in it stops when i click "stop".

p12tic commented 5 years ago

I saw issues like this sometimes. Particularly when the barrier connection is severed in unclean fashion (e.g. removed cable). I have to kill processes manually in order to be able to restart.

p12tic commented 5 years ago

Note, that when closing the application via the 'X' button, it does not quit as intended. An icon should be shown in the notification area of the desktop environment which allows to bring back barrier and stop it.

allanwmacdonald commented 5 years ago

@Abh15h3k:

I would like to dispute your assertion that the 'X' button means "minimize" and the program is working as intended. It is my and, likely many others' understanding that the program ought to work this way (on either platform):

  1. When starting barrier with no previous instance of the application or background processes running, the barrier control gui should open up and nothing else. You can then select either server or client configuration, perform setups, etc. If you close the barrier application at this time, the configuration should be saved (perhaps by prompting the user) and the barrier process should end.

  2. Pressing "Start" in the barrier gui should start the background process (i.e. barrierc, barrierd or barriers or whatever), depending on whether we are starting a client or a server.

  3. Pressing "Stop" should kill the background process that was previously launched.

  4. Normally, 'X' means "Stop", not "Minimize". Pressing 'X' should kill the barrier gui (foreground) application, leaving any background process running (the server or client).

  5. Starting up the barrier gui with a background process running should cause a single instance of the barrier gui to launch, referencing the existing background process that is running. It should not be possible to open multiple instances of the barrier gui by clicking on the icon for the running instance.

  6. If the gui is invoked from the shell, and the 'X' button is pressed, execution in the shell should return to the command prompt.

  7. Pressing an explicit "minimize" button should be the way to keep the barrier gui application process running if you want.

These are all reasonable expectations as to how a program like this ought to work.

Perhaps the best way to do this is as follows (on linux):

  1. Establish ability to start up barrier client or server from the command-line using linux-customary daemon (systemd) and configuration methods (.conf files).

  2. The gui's sole purpose should be to edit the configuration and start and stop the server or client daemon (i.e. act as a wrapper for the command line actions).

Equivalents can be made for the windows platform.

AdrianKoshka commented 5 years ago

The meaning of 'X' is contextually dependent, and how barrier behaves now, is how I've seen most foreground/background applications behave.

Abh15h3k commented 5 years ago

@allanwmacdonald. if you have used Skype or Discord. you will know that in any situation pressing 'X' does not actually stop/kill the program. it minimizes to the system tray. this behavior is what i label as "intended". The other reason im sure that this aspect is working correctly is that i own Synergy ( from Symeless ). and in that whenever i press 'X' in any situation it minimizes to system tray or turn into a icon in linux as a background process.

my original issue was that when i press "Stop" (after having started as server or client) i am still able to share my mouse n keyboard. which is a huge problem while playing games. just today barrier was running and it kept crossing over to my other pc and i was loosing my mind. then i realised barrier server hadnt actually stopped so to fix that I had to go to my Task Manager and select "barriers.exe" and "End Proccess" it.

edit: when i say skype i dont mean the windows app store skype. i mean the skype that we install. skype for business is also a good example

allanwmacdonald commented 5 years ago

I think you are missing the point: This program is not a single executable. There are components that must be started and stopped independently. The gui which controls the background services only needs one single instance and I don't know why it needs to be running all the time. You only need it when you want to start or stop the background process. If you actually end the GUI process after closing the window, the program as a whole is still operating because another component, the service in the background, continues to run; i.e. the "tray" as you put it.

It seems to me that some understanding of what must remain running and what must end, when the 'X' is clicked, or STOP is clicked, is the point of contention here. The problems I see with not exiting the gui when clickng 'X" are as follows:

  1. If the gui was invoked from a desktop icon or menu, and X is clicked thereafter, a subsequent invocation of the GUI app causes a NEW process to be created, not the same old process to be brought up.

  2. The desktop environment (in my case Mate but I will switch to Unity or Gnome later to test), there does not seem to be any way to bring up the original instance of the GUI once the window has been closed by clicking X. So the only way to bring up the GUI to, say, stop a running service, is to click the icon, which causes a NEW instance of the gui process to start. Do this a few times and you have a whole bunch of GUI processes clogging up your memory!

So, I guess I don't care if the button is X or F or whatever as long as we don't have a bunch of new processes piling up!

snuq commented 5 years ago

Back on the actual subject of the bug.... I'm having the same issue on my server machine, the barriers.exe is not shutting down (on windows 8.1). I never had this happen for the many months when I was running version 2.1, but upon upgrading to 2.3.1 it happened immediately.

nsssim commented 3 years ago

Reinstalling the application on windows 10 did fix the problem (running as sever)

furetosan commented 3 years ago

Hi,

Not sure this is the place...

I've managed to confirm that barrierc.exe and barrierd.exe not only do not terminate on close, but also seem to run on startup for some reason?

Cheers

carwin commented 3 years ago

I've been having the same issue on a Windows 10 host running 2.3.3.

To add to the report, it looks like there is some sort of start up trouble when you've manually terminated the background processes. The log, after terminating manually through Task Manager and re-running Barrier, is filled with a non-stop barrage of:

INFO: connecting to service...
ERROR: ipc connection error, connection refused

It also appears that after the manual termination and re-opening of Barrier that the barrierc process does not respawn.

So to summarize, Barrier 2.3.3 & Windows 10: