github-starred/barrier

Fork 0

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

[GH-ISSUE #297] Unable to run Linux barrier client during startup using systemd #238

New issue

Closed

opened 2026-05-05 05:46:08 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 05:46:08 -06:00

Owner

Originally created by @vnktsh on GitHub (May 1, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/297

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

Originally created by @vnktsh on GitHub (May 1, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/297 ### 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` 3. Barrier manages to startup but throws error: "**WARNING: secondary screen unavailable: unable to open screen**" 4. 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 ```

gitea-mirror closed this issue

2026-05-05 05:46:10 -06:00

gitea-mirror commented

2026-05-05 05:46:14 -06:00

Author

Owner

@noisyshape commented on GitHub (May 1, 2019):

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 commented on GitHub (May 1, 2019): 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

gitea-mirror commented

2026-05-05 05:46:17 -06:00

Author

Owner

@vnktsh commented on GitHub (May 3, 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 commented on GitHub (May 3, 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.

gitea-mirror commented

2026-05-05 05:46:20 -06:00

Author

Owner

@RPGillespie6 commented on GitHub (Jan 11, 2020):

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 commented on GitHub (Jan 11, 2020): 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

gitea-mirror commented

2026-05-05 05:46:23 -06:00

Author

Owner

@RPGillespie6 commented on GitHub (Jan 11, 2020):

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 commented on GitHub (Jan 11, 2020): 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

gitea-mirror commented

2026-05-05 05:46:26 -06:00

Author

Owner

@reynoldscem commented on GitHub (Oct 27, 2020):

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

@reynoldscem commented on GitHub (Oct 27, 2020): @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`.

gitea-mirror commented

2026-05-05 05:46:27 -06:00

Author

Owner

@Maurits2014 commented on GitHub (Mar 16, 2021):

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.

@Maurits2014 commented on GitHub (Mar 16, 2021): 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.

No labels

Rows
Columns