Starting barrerc on boot using systemd on Ubuntu system

[Karlovsky120]

Operating Systems

Server: Windows 10 1903

Client: Ubuntu 18.04

Barrier Version

2.1.0-RELEASE-0b2dfd80

Steps to reproduce bug

I'm trying to get the barrierc to start on boot. System is set to auto logon and I have a systemd service that looks like this:

[Unit]
Description=Barrier mouse/keyboard share
Requires=display-manager.service
After=display-manager.service network.target

[Service]
Type=forking
ExecStart=/usr/bin/barrierc -f 192.168.12.96
Restart=always
RestartSec=2
User=karlovsky120

[Install]
WantedBy=default.target

I can run '/usr/bin/barrier -f 192.168.12.96 manually from the terminal and barrier will start normally and connect to the server.

If I attempt to systemctl start barrier.service, it says that the job failed because a fatal signal was delivered causing control process to dump code. I've spent last several days trying to get this to work and nothing I tried works.

Can someone tell me the minimal Ubuntu systemd service file that will work for barrierc, assuming that the service starts on boot and that auto logon is enabled?

[maluramichael]

I get the following error

Feb 04 20:23:22 sirius systemd[1]: barrier.service: Control process exited, code=killed, status=6/ABRT
Feb 04 20:23:22 sirius systemd[1]: barrier.service: Failed with result 'signal'.
Feb 04 20:23:22 sirius systemd[1]: Failed to start Barrier mouse/keyboard share.
Feb 04 20:23:27 sirius systemd[1]: barrier.service: Service RestartSec=5s expired, scheduling restart.
Feb 04 20:23:27 sirius systemd[1]: barrier.service: Scheduled restart job, restart counter is at 10.
Feb 04 20:23:27 sirius systemd[1]: Stopped Barrier mouse/keyboard share.
Feb 04 20:23:27 sirius systemd[1]: Starting Barrier mouse/keyboard share...
Feb 04 20:23:27 sirius barrierc[25997]: [2020-02-04T20:23:27] DEBUG: XOpenDisplay(":0.0")
Feb 04 20:23:27 sirius barrierc[25997]:         /home/michael/tools/barrier/src/lib/platform/XWindowsScreen.cpp,888
Feb 04 20:23:27 sirius barrierc[25997]: No protocol specified
Feb 04 20:23:27 sirius barrierc[25997]: [2020-02-04T20:23:27] WARNING: secondary screen unavailable: unable to open screen
Feb 04 20:23:27 sirius barrierc[25997]:         /home/michael/tools/barrier/src/lib/barrier/ClientApp.cpp,404
Feb 04 20:23:27 sirius barrierc[25997]: [2020-02-04T20:23:27] DEBUG: retry in 60 seconds
Feb 04 20:23:27 sirius barrierc[25997]:         /home/michael/tools/barrier/src/lib/barrier/ClientApp.cpp,275
Feb 04 20:23:27 sirius barrierc[25997]: [2020-02-04T20:23:27] DEBUG: event queue is ready
Feb 04 20:23:27 sirius barrierc[25997]:         /home/michael/tools/barrier/src/lib/base/EventQueue.cpp,117
Feb 04 20:23:27 sirius barrierc[25997]: barrierc: /home/michael/tools/barrier/src/lib/base/NonBlockingStream.cpp:56: bool NonBlockingStream::try_read_char(char&) const: Assertion `result == -1 && (errno == EAGAIN || errno == EWOULDBLOCK)' failed.

Looks like it cannot open the screen when its started from a service. https://unix.stackexchange.com/a/486095

[Karlovsky120]

I just want to do the Ubuntu equivalent of Windows "run on startup" (which works flawlessly on for Barrier).
Why is this so hard on Ubuntu?

[maxiberta]

Startup Applications is the equivalent on Ubuntu with the default Gnome session. Have you tried adding Barrier (the GUI app) in client mode there?

https://help.ubuntu.com/stable/ubuntu-help/startup-applications.html.en

[Karlovsky120]

I was not aware of that, when I looked for starting barrier with ubuntu I got a lot of systemd guides. I'll give it a shot, but it looks like it's going to work.

[toloveru]

I seem to be getting the same issue on Fedora when I start the client from a screen session with it immediately detached (screen -dmS barrier barrierc -f --no-tray --debug INFO --name desktop --enable-crypto thonkpad). However when starting with the screen session attached (i.e. -mS) it starts fine and the screen can be detached afterwards. I tried to make line 57 in src/lib/base/NonBlockingStream.cpp return true but the issue persists. Perhaps the systemd unit and a detached screen don't provide a full tty or something like that? Not sure...

[simons-public]

@Karlovsky120 I found your issue looking for something else. I realize this is old, but I noticed that your service had

Type=forking
ExecStart=/usr/bin/barrierc -f 192.168.12.96

If barrierc is run with the -f or --no-daemon options it will not fork, but stay in the foreground. You could try changing the [Service] Type to simple. You also have to either set the $DISPLAY environment variable or specify the X11 display with --display.

Also, I have a pull request in for some systemd service configurations #694 if you want to try them out.

[toloveru]

Interesting, does the systemd unit also launch without the assertion failure? I seem to be able to use the Debian 10 distribution package on those systems fine with screen detached immediately, and I believe the systemd unit as well. However on both Fedora 31 and Devuan ASCII (Debian 9 like) where I had to build from source, I was never able to get either detached screen (or on Fedora the systemd unit) to work properly. Always it was that assertion failure. No idea why though, my systemd unit even had the environment set with the DISPLAY=:0 variable and everything. Very strange...

[simons-public]

@toloveru It should launch without the above mentioned assertion failure as long as your X11 display is :0. The error above looks like what happens when barrier tries to launch and the $DISPLAY variable isn't set. Barrier will default to trying :0.0 which is a fallback guess.

Systemd doesn't know what the $DISPLAY variable is for the current X11 session, the only way I know to make it work is explicitly set it with --display in the barrier arguments.

Edit: That might also be what's happening in your screen session if you're using ssh and don't have $DISPLAY set or if you have X11 forwarding on.

[toloveru]

@simons-public Thanks for the reply. I've just built Barrier from the current master (dbd1082) on Fedora 31, adjusted to include your systemd units. It appears that the client starts as expected over SSH even with DISPLAY=:0 unset and --display :0 not passed (I suppose using this fallback variable?). In the systemd unit I found that the program path is /usr/bin rather than /usr/local/bin which the source build of Barrier seems to install to. I don't know if this is intended? In screen however it appears that the assertion failure still occurs, as well as in the systemd unit but there the display doesn't seem to be found either. When opening a local terminal I seem to have $DISPLAY set to :0 as I would expect. So X11 must be running there. It's odd that the assertion failure occurs on how screen is run (detached or attached) regardless of the state of --display and $DISPLAY, and works as intended when run directly from the console (even over SSH) as well. Could it be that these are 2 separate issues?
Attached are output from screen and systemd respectively.

[shymega]

Looking at that systemd output, my hunch is that its not able to find $HOME/.Xauthority, or that it doesn't have permissions for it. You could try disabling X authentication w/ xhost +... but this is just a hunch. I'm not saying it is the issue or not.

[CathalMullan]

Using unbuffer (from the expect package) bypasses the NonBlockingStream issue.
I've got a working service from the following config.

[Unit]
Description=Barrier KVM Client
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/unbuffer /usr/bin/barrierc --no-daemon --enable-crypto --display :0 192.168.0.15:24800
Environment=XAUTHORITY=/var/run/lightdm/root/:0
Restart=always
RestartSec=3

[Install]
WantedBy=graphical.target

[RobQ27]

[Unit]
Description=Barrier Client daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/barrierc --daemon --disable-crypto --display :0 -f 192.xx.xx.xx
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

I just get into Linux, i try to start Barrier at Startup without Login.

Barrier is starting but it ignores the Login Screen and the User is loged in.

How can i avoid the login