mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #734] Barrier client coredumps when run as systemd service #575
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#575
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 @jmartens on GitHub (Jun 3, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/734
Operating Systems
Operating Systems
Server: Windows 10 Professional 1909
Client: Ubuntu 20.04 LTS
Barrier Version
Server: 2.3.2-snapshot-210cb270
Client: 2.3.2-snapshot-0a1f0802 (latest master)
Steps to reproduce bug (see also #733)
systemctl daemon-reloadOther info
core dump:
core.barrierc.0.fe76b36acc64456b893a583eb3c1ae9f.9270.1591211953000000000000.zip
@jmartens commented on GitHub (Jun 3, 2020):
When ExecStartPre steps are done manually it is possible to start the barrier running in client mode using the same command from a terminal window though. Systemd does not allow it apparently.
@simons-public commented on GitHub (Jun 6, 2020):
@jmartens is this the same issue as #733?
@jmartens commented on GitHub (Jun 6, 2020):
No, this is a core dump where #733 is just a failure since the command fails to execute, look at the exit codes:
#734: (code=dumped, signal=ABRT)
vs
#733 (code=exited, status=203/EXEC)
The core dump as described here only appears after manually working around the ExecStartPre failures described in #733.
@nlutterman commented on GitHub (Aug 31, 2020):
So, just to mention - I'm not sure the problem stems from elsewhere - but I removed an assertion from the code that allowed me to launch Barrier as a systemd service prior to logging in. I was having this same core dump occur for me.
When I get some time I'll look into it again, but I removed this assertion:
5a02070b54/src/lib/base/NonBlockingStream.cpp (L56)I rebuilt and could run barrierc without issue as a systemd service.
Git blame shows a comment which states:
Unfortunately I don't know enough to state whether the assertion is correct when comparing the context of using read for the parent stream's event queue and how that ties into
barriercbeing run as a systemd service.@GeoMaciolek commented on GitHub (Dec 11, 2020):
Short Version
You can work around this by prefixing the command with
unbuffer- available in Debian/etc in theexpectpackage.Longer Version
So, on a hunch, I tried a few things and came up with a workaround! Wrapping the
barrierccommand inunbufferfrom theexpectpackage does some magic withI can use it in systemd, and I can also get it to launch via SSH (in other words,
ssh '/usr/bin/barrierc -f ...)There's still some fun because my system has encrypted home folders, and it's looking for
/home/MYUSERNAME/.local/share/barrier/SSL/Fingerprints/TrustedServers.txt- so, I'll try to figure out if there's a way to specify an alternate location (or if I want to create that file in the "parent" path, so it will appear before the real home FS is mounted?)Example "Remote Launch" Script
barrierc-remote-ssh.sh
You should create /var/log/barrier/ on the server and give access, ala
sudo mkdir /var/log/barrier;sudo chmod 777 /var/log/barrier- and note that this will probably only work if you're already logged in. (You need to much about with the xauthority file, as shown in the launch scripts.ssh MYUSERNAME@MYCLIENTNAME unbuffer /usr/bin/barrierc --no-tray --no-restart --debug INFO --name arthur --enable-crypto --log /var/log/barrier/barrier2.log --display :0 [MYSERVER]:24800Example Systemd Unit Files
Here are my systemd unit files WARNING: THIS MESSES WITH SYSTEM SECURITY by changing permissions on the X Authoruty file.
Also, these won't work with encrypted home stuff. (at least not until you SSH in)
/etc/systemd/system/barrier-pre.service
/etc/systemd/system/barrier.service
@mirh commented on GitHub (Oct 7, 2021):
Does #694 fixes/improves this?