mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #540] Starting barrerc on boot using systemd on Ubuntu system #419
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#419
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Karlovsky120 on GitHub (Jan 11, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/540
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 commented on GitHub (Feb 4, 2020):
I get the following error
Looks like it cannot open the screen when its started from a service. https://unix.stackexchange.com/a/486095
@Karlovsky120 commented on GitHub (Feb 4, 2020):
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 commented on GitHub (Feb 4, 2020):
Startup Applicationsis 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 commented on GitHub (Feb 4, 2020):
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 commented on GitHub (Mar 28, 2020):
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 commented on GitHub (May 28, 2020):
@Karlovsky120 I found your issue looking for something else. I realize this is old, but I noticed that your service had
If
barriercis run with the-for--no-daemonoptions it will not fork, but stay in the foreground. You could try changing the [Service] Type tosimple. You also have to either set the$DISPLAYenvironment 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 commented on GitHub (May 28, 2020):
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 commented on GitHub (May 28, 2020):
@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.0which 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
--displayin 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 commented on GitHub (May 28, 2020):
@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=:0unset and--display :0not 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$DISPLAYset to:0as 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--displayand$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 commented on GitHub (May 28, 2020):
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 commented on GitHub (Jan 3, 2021):
Using unbuffer (from the
expectpackage) bypasses the NonBlockingStream issue.I've got a working service from the following config.
@RobQ27 commented on GitHub (May 25, 2023):
[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