Unable to run Linux barrier client during startup using systemd

[vnktsh]

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

1. Goal is to make Linux barrier client to startup during boot
2. Setup systemd srevice script [attached service script below]
3. sudo systemctl start barrier.service
4. Barrier manages to startup but throws error: "WARNING: secondary screen unavailable: unable to open screen"
5. 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

[noisyshape]

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

[vnktsh]

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

[RPGillespie6]

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]

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

[reynoldscem]

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

[Maurits2014]

After trying a number of things, what ended up working for me were adding the "--display :0" option and setting XAUTHORITY="/home/maurits/.Xauthority".

My setup has two devices that need to be connected to a Windows host, and for that matter I created systemd services that are run on boot right when Openbox starts, and these two changes finally made that work.