Barrier: Unable to run Linux barrier client during startup using systemd

Created on 1 May 2019 · 5Comments · Source: debauchee/barrier

Operating Systems

Server: Windows 10 Version 1709 (OS Build 16299.1087)
Client: Ubuntu 18.04 (GNOME 3 desktop)

Barrier Version

Server: 2.2.0
Client: 2.2.0

Steps to reproduce bug

Goal is to make Linux barrier client to startup during boot
Setup systemd srevice script [attached service script below]
sudo systemctl start barrier.service
Barrier manages to startup but throws error: "WARNING: secondary screen unavailable: unable to open screen"
Fails to connect to server

Other info

When did the problem start to occur?
When trying to setup systemd service.
Is there a way to work around it?
Not, if you want barrier to startup before logging in the user.
Does this bug prevent you from using Barrier entirely?
No

Put anything else you can think of here.

My service script under /etc/systemd/system/barrier.service

[Unit]
Description=Start Barrier client during boot

[Service]
Type=simple
Restart=always
RestartSec=2
ExecStart=/usr/bin/barrierc -f --debug DEBUG2 --log /tmp/barrier-service.log --name ubuntu-Desktop [<server-info>]:24800

[Install]
WantedBy=multi-user.target

Logs:

tail -f /tmp/barrier-service.log 

[2019-04-30T22:26:50] DEBUG: XOpenDisplay(":0.0")
[2019-04-30T22:26:50] WARNING: secondary screen unavailable: unable to open screen
[2019-04-30T22:26:50] DEBUG: retry in 60 seconds
[2019-04-30T22:27:50] DEBUG: XOpenDisplay(":0.0")
[2019-04-30T22:27:50] WARNING: secondary screen unavailable: unable to open screen
[2019-04-30T22:27:50] DEBUG: retry in 60 seconds

Source

vnktsh

Most helpful comment

Note that it works if I launch barrier natively (i.e. not over ssh), but that defeats the whole purpose of barrier since I need to plug in a second keyboard and mouse to do so

RPGillespie6 on 11 Jan 2020

👍2

All 5 comments

If I had to guess I would say that it's running too early and Barrier doesn't correct for it. Using your display manager to start and stop Barrier might work. Or instead of running Barrier as root you could log in automatically. Pick your poison.

See also #179 and #185

noisyshape on 1 May 2019

Thanks @noisyshape , I'll read the references you mentioned. I believe this is a Linux problem rather than Barrier. I'm closing it now.

vnktsh on 4 May 2019

This is happening to me too, except I'm trying to launch barrier over ssh. This is what I get:

user@xenon:~$ /snap/barrier-kvm/2/bin/barrierc -f --no-tray --debug DEBUG --name xenon [192.168.1.192]:24800
[2020-01-11T15:09:06] DEBUG: XOpenDisplay(":0.0")
Invalid MIT-MAGIC-COOKIE-1 key[2020-01-11T15:09:06] WARNING: secondary screen unavailable: unable to open screen
[2020-01-11T15:09:06] DEBUG: retry in 60 seconds
[2020-01-11T15:09:06] DEBUG: event queue is ready
[2020-01-11T15:10:06] DEBUG: XOpenDisplay(":0.0")
Invalid MIT-MAGIC-COOKIE-1 key[2020-01-11T15:10:06] WARNING: secondary screen unavailable: unable to open screen
[2020-01-11T15:10:06] DEBUG: retry in 60 seconds
[2020-01-11T15:11:06] DEBUG: XOpenDisplay(":0.0")
Invalid MIT-MAGIC-COOKIE-1 key[2020-01-11T15:11:06] WARNING: secondary screen unavailable: unable to open screen
[2020-01-11T15:11:06] DEBUG: retry in 60 seconds

I'm using Xubuntu 18.04.3

RPGillespie6 on 11 Jan 2020

👍1

Note that it works if I launch barrier natively (i.e. not over ssh), but that defeats the whole purpose of barrier since I need to plug in a second keyboard and mouse to do so

RPGillespie6 on 11 Jan 2020

👍2

@RPGillespie6 Not sure if this is the same problem as you, but I got round this just by starting barriers over ssh using --display :1.