github-starred/barrier

Fork 0

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

[GH-ISSUE #200] Executing barrierc makes terminal line invisible #163

New issue

Open

opened 2026-05-05 05:28:23 -06:00 by gitea-mirror · 13 comments

gitea-mirror commented

2026-05-05 05:28:23 -06:00

Owner

Originally created by @htamop on GitHub (Dec 17, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/200

Originally assigned to: @AdrianKoshka on GitHub.

Operating Systems

Server: Microsoft 10 Enterprise

Client: Ubuntu 18.04

Barrier Version

Windows 10 : 2.1.0-release-0b2dfd80
Ubuntu 18.04 : 2.1.0-snapshot-8b69f9fe

Steps to reproduce bug

Open terminal
Execute command : barrierc <Your server Address>
Bug occurs.

Bug 1 : Terminal output becomes invisible.
Bug 2 : Client doesn't work.

Other info

However, when executing command with --no-daemon option, it worked.
I'd like to add barrierc into Ubuntu Startup Applications Preferences instead of manually starting barrier whenever I start ubuntu.

Please share your thought

Originally created by @htamop on GitHub (Dec 17, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/200 Originally assigned to: @AdrianKoshka on GitHub. ### Operating Systems ### Server: Microsoft 10 Enterprise Client: Ubuntu 18.04 ### Barrier Version ### Windows 10 : 2.1.0-release-0b2dfd80 Ubuntu 18.04 : 2.1.0-snapshot-8b69f9fe ### Steps to reproduce bug ### 1. Open terminal 2. Execute command : barrierc \<Your server Address\> 3. Bug occurs. Bug 1 : Terminal output becomes invisible. Bug 2 : Client doesn't work. ### Other info ### However, when executing command with --no-daemon option, it worked. I'd like to add barrierc into Ubuntu Startup Applications Preferences instead of manually starting barrier whenever I start ubuntu. Please share your thought

gitea-mirror added the

macOS

bug

linux

labels 2026-05-05 05:28:23 -06:00

gitea-mirror commented

2026-05-05 05:28:27 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Dec 17, 2018):

Bug 2 : Client doesn't work.

Could I get more information?

(Probably not related, but, I'm going to assume you've added barrier to the windows firewall?)

I'd like to add barrierc into Ubuntu Startup Applications Preferences

Correct me if I'm wrong, but I thought the barrier (GUI) client had an autostart option?

@AdrianKoshka commented on GitHub (Dec 17, 2018): > Bug 2 : Client doesn't work. Could I get more information? (Probably not related, but, I'm going to assume you've [added barrier to the windows firewall](https://github.com/debauchee/barrier/wiki/Adding-Barrier-to-the-Windows-Firewall)?) > I'd like to add barrierc into Ubuntu Startup Applications Preferences Correct me if I'm wrong, but I thought the barrier (GUI) client had an autostart option?

gitea-mirror commented

2026-05-05 05:28:30 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Dec 17, 2018):

fwiw, I'll run an ubuntu 18.04 vm, and test barrierc to see if it does what you say it does. Seems easily reproducible.

@AdrianKoshka commented on GitHub (Dec 17, 2018): fwiw, I'll run an ubuntu 18.04 vm, and test `barrierc` to see if it does what you say it does. Seems easily reproducible.

gitea-mirror commented

2026-05-05 05:28:33 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Dec 17, 2018):

Seems running barriers made terminal input invisible... (haven't tested barrierc yet, just an observation while setting up barriers on the same VM)

@AdrianKoshka commented on GitHub (Dec 17, 2018): Seems running `barriers` made terminal input invisible... (haven't tested `barrierc` yet, just an observation while setting up `barriers` on the same VM)

gitea-mirror commented

2026-05-05 05:28:35 -06:00

Author

Owner

@htamop commented on GitHub (Dec 17, 2018):

Bug 2 : Client doesn't work.

Could I get more information?

(Probably not related, but, I'm going to assume you've added barrier to the windows firewall?)

I'd like to add barrierc into Ubuntu Startup Applications Preferences

Correct me if I'm wrong, but I thought the barrier (GUI) client had an autostart option?

@AdrianKoshka I already have added barrier to the windows 10 firewall (I wasted a lot time to solve that by myself a month ago) I should had uploaded my solving story.
According to your test, both barriers and barrierc have the invisible problem regardless using vm.
If I'm available sometime, I will try to fix this..
Or, if there is someone who is kind, please fix this non-fatal issue

@htamop commented on GitHub (Dec 17, 2018): > > Bug 2 : Client doesn't work. > > Could I get more information? > > (Probably not related, but, I'm going to assume you've [added barrier to the windows firewall](https://github.com/debauchee/barrier/wiki/Adding-Barrier-to-the-Windows-Firewall)?) > > > I'd like to add barrierc into Ubuntu Startup Applications Preferences > > Correct me if I'm wrong, but I thought the barrier (GUI) client had an autostart option? @AdrianKoshka I already have added barrier to the windows 10 firewall (I wasted a lot time to solve that by myself a month ago) I should had uploaded my solving story. According to your test, both barriers and barrierc have the invisible problem regardless using vm. If I'm available sometime, I will try to fix this.. Or, if there is someone who is kind, please fix this non-fatal issue

gitea-mirror commented

2026-05-05 05:28:39 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Dec 17, 2018):

if you want a temporary work around (I noticed the GUI doesn't work OOTB on ubuntu 18.04), I can give you one:

go to the releases page
download the .tar.gz for 2.1.1 (or just click that link)
once downloaded, extract it
follow these instructions to compile barrier:

sudo apt update && sudo apt upgrade
sudo apt install git cmake make xorg-dev g++ libcurl4-openssl-dev \
                 libavahi-compat-libdnssd-dev libssl-dev libx11-dev \
                 libqt4-dev qtbase5-dev
cd barrier-2.1.1 #(the extracted .tar.gz)
./clean_build.sh
cd build
sudo make install  # installs to /usr/local/

This doesn't solve the whole disappearing input, but it does solve the GUI not working.

@AdrianKoshka commented on GitHub (Dec 17, 2018): if you want a temporary work around (I noticed the GUI doesn't work OOTB on ubuntu 18.04), I can give you one: 1. go to the releases page 2. download the [.tar.gz](https://github.com/debauchee/barrier/archive/v2.1.1.tar.gz) for 2.1.1 (or just click that link) 3. once downloaded, extract it 4. follow these instructions to compile barrier: ``` sudo apt update && sudo apt upgrade sudo apt install git cmake make xorg-dev g++ libcurl4-openssl-dev \ libavahi-compat-libdnssd-dev libssl-dev libx11-dev \ libqt4-dev qtbase5-dev cd barrier-2.1.1 #(the extracted .tar.gz) ./clean_build.sh cd build sudo make install # installs to /usr/local/ ``` This doesn't solve the whole disappearing input, but it does solve the GUI not working.

gitea-mirror commented

2026-05-05 05:28:41 -06:00

Author

Owner

@memecode commented on GitHub (Dec 17, 2018):

This is also an issue on mac os x, reproduced on 10.13.4.

@memecode commented on GitHub (Dec 17, 2018): This is also an issue on mac os x, reproduced on 10.13.4.

gitea-mirror commented

2026-05-05 05:28:45 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 1, 2019):

I have this issue too and looked into the cause.

barrier is setup to always check if there is input on stdin. The only thing its looking for is to see if the user pressed 'S', which will trigger a shutdown/exit. The code that is making stdin non-blocking is the thing messing up the terminal (NonBlockingStream).

When you daemonize its common practice to re-open stdin/stdout/stderr as /dev/null, which barrier is doing. This however causes a problem because its still trying to read input from stdin for the 'S' check. This ends up triggering the assert() in

bool NonBlockingStream::try_read_char(char &ch) const
{
    int result = read(_fd, &ch, 1);
    if (result == 1)
        return true;

    assert(result == -1 && (errno == EAGAIN || errno == EWOULDBLOCK));
    return false;
}

The read() of stdin (/dev/null) is returning 0.

Personally I think it would make the most sense to just remove the stdin monitoring code. The user can just do ctrl-c if they wanna kill barrier when its in non-daemon mode. If you are ok with that I can make a PR removing it.

@jwestfall69 commented on GitHub (Jan 1, 2019): I have this issue too and looked into the cause. barrier is setup to always check if there is input on stdin. The only thing its looking for is to see if the user pressed 'S', which will trigger a shutdown/exit. The code that is making stdin non-blocking is the thing messing up the terminal (NonBlockingStream). When you daemonize its common practice to re-open stdin/stdout/stderr as /dev/null, which barrier is doing. This however causes a problem because its still trying to read input from stdin for the 'S' check. This ends up triggering the assert() in ``` bool NonBlockingStream::try_read_char(char &ch) const { int result = read(_fd, &ch, 1); if (result == 1) return true; assert(result == -1 && (errno == EAGAIN || errno == EWOULDBLOCK)); return false; } ``` The read() of stdin (/dev/null) is returning 0. Personally I think it would make the most sense to just remove the stdin monitoring code. The user can just do ctrl-c if they wanna kill barrier when its in non-daemon mode. If you are ok with that I can make a PR removing it.

gitea-mirror commented

2026-05-05 05:28:47 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 1, 2019):

@jwestfall69 This makes sense to me, feel free to do a PR :-)

@p12tic commented on GitHub (Jan 1, 2019): @jwestfall69 This makes sense to me, feel free to do a PR :-)

gitea-mirror commented

2026-05-05 05:28:50 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 1, 2019):

Looks like this will be a little more involved. The GUI app spawns the cli then is using the 'S' char when it wants the cli to shutdown. I will see if I can come up with something to still fix the issue

@jwestfall69 commented on GitHub (Jan 1, 2019): Looks like this will be a little more involved. The GUI app spawns the cli then is using the 'S' char when it wants the cli to shutdown. I will see if I can come up with something to still fix the issue

gitea-mirror commented

2026-05-05 05:28:52 -06:00

Author

Owner

@EvanEdwards commented on GitHub (Aug 20, 2019):

Incidentally, the classic way to fix this as a user is to type (blindly) the commandline:

stty sane

Which fixes just about all tty issues. Hopefully that's a useful tip for people running into this and needing a quick fix.

@EvanEdwards commented on GitHub (Aug 20, 2019): Incidentally, the classic way to fix this as a user is to type (blindly) the commandline: stty sane Which fixes just about all tty issues. Hopefully that's a useful tip for people running into this and needing a quick fix.

gitea-mirror commented

2026-05-05 05:28:55 -06:00

Author

Owner

@bb00 commented on GitHub (Aug 27, 2019):

Or
stty -raw echo

@bb00 commented on GitHub (Aug 27, 2019): Or `stty -raw echo`

gitea-mirror commented

2026-05-05 05:28:57 -06:00

Author

Owner

@zouyonghao commented on GitHub (Mar 26, 2020):

I have the same issue, any updates for this?

@zouyonghao commented on GitHub (Mar 26, 2020): I have the same issue, any updates for this?

gitea-mirror commented

2026-05-05 05:28:59 -06:00

Author

Owner

@bb00 commented on GitHub (Mar 31, 2020):

You can also run with the -f flag set if I recall correctly which will run the client in the background.

@bb00 commented on GitHub (Mar 31, 2020): You can also run with the -f flag set if I recall correctly which will run the client in the background.

No labels

Rows
Columns