Barrier: Executing barrierc makes terminal line invisible

[htamop]

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 \
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

[AdrianKoshka]

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]

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]

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

[htamop]

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

[AdrianKoshka]

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 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.

[memecode]

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

[jwestfall69]

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.

[p12tic]

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

[jwestfall69]

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

[EvanEdwards]

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.

[bb00]

Or
stty -raw echo

[zouyonghao]

I have the same issue, any updates for this?

[bb00]

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