[GH-ISSUE #734] Barrier client coredumps when run as systemd service #575

Open
opened 2026-05-05 06:42:25 -06:00 by gitea-mirror · 6 comments
Owner

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)

  1. Build using CMAKE install target set to /usr
  2. make install
  3. sudo systemctl start barrierc@ip-of-master.service
  4. Manually run pre-exec steps:
export FP_DIR=/var/lib/barrier/barrier@ip-of-master/barrier/SSL/Fingerprints
sudo /usr/bin/mkdir -p "${FP_DIR}"
sudo usr/bin/sh -c "[ -f "${FP_DIR}/TrustedServers.txt" ] ||\
openssl s_client -connect %i:24800 2>/dev/null |\
openssl x509 -noout -sha1 -fingerprint |\
grep -oE '([A-Z0-9]{2}:?){20}' > ${FP_DIR}/TrustedServers.txt"
  1. Check to see stuff is there:
total 20
drwxr-xr-x  5 root root 4096 jun  3 21:08 .
drwxr-xr-x 87 root root 4096 jun  1 10:41 ..
drwxr-xr-x  3 root root 4096 jun  1 11:23 barrier@ip-of-master
wc -l /var/lib/barrier/barrier@ip-of-master/barrier/SSL/Fingerprints/TrustedServers.txt 
1 /var/lib/barrier/barrier@ip-of-master/barrier/SSL/Fingerprints/TrustedServers.txt
  1. Comment out ExexStartPre steps in barrierc@.service
  2. Make sure changes are approved by systemd
    systemctl daemon-reload
  3. Start service and check status
➜  system sudo systemctl status barrierc@ip-of-master.service --no-pager --full                     
● barrierc@ip-of-master.service - Barrier Client connected to ip-of-master (Open-source KVM software)
     Loaded: loaded (/usr/local/lib/systemd/system/barrierc@.service; enabled; vendor preset: enabled)
     Active: failed (Result: core-dump) since Wed 2020-06-03 21:19:13 CEST; 3s ago
       Docs: man:barrierc(1)
             man:barriers(1)
             https://github.com/debauchee/barrier/wiki
    Process: 9270 ExecStart=/usr/local/bin/barrierc --enable-crypto --display ${DISPLAY} --debug ${LOG_LEVEL} --no-daemon ip-of-master (code=dumped, signal=ABRT)
   Main PID: 9270 (code=dumped, signal=ABRT)

jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Main process exited, code=dumped, status=6/ABRT
jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Failed with result 'core-dump'.
jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Scheduled restart job, restart counter is at 5.
jun 03 21:19:13 hostname-of-client systemd[1]: Stopped Barrier Client connected to ip-of-master (Open-source KVM software).
jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Start request repeated too quickly.
jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Failed with result 'core-dump'.
jun 03 21:19:13 hostname-of-client systemd[1]: Failed to start Barrier Client connected to ip-of-master (Open-source KVM software).

Other info

core dump:
core.barrierc.0.fe76b36acc64456b893a583eb3c1ae9f.9270.1591211953000000000000.zip

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) 1. Build using CMAKE install target set to /usr 2. make install 3. sudo systemctl start barrierc@ip-of-master.service 4. Manually run pre-exec steps: ``` export FP_DIR=/var/lib/barrier/barrier@ip-of-master/barrier/SSL/Fingerprints sudo /usr/bin/mkdir -p "${FP_DIR}" sudo usr/bin/sh -c "[ -f "${FP_DIR}/TrustedServers.txt" ] ||\ openssl s_client -connect %i:24800 2>/dev/null |\ openssl x509 -noout -sha1 -fingerprint |\ grep -oE '([A-Z0-9]{2}:?){20}' > ${FP_DIR}/TrustedServers.txt" ``` 5. Check to see stuff is there: ```ls -la /var/lib/barrier total 20 drwxr-xr-x 5 root root 4096 jun 3 21:08 . drwxr-xr-x 87 root root 4096 jun 1 10:41 .. drwxr-xr-x 3 root root 4096 jun 1 11:23 barrier@ip-of-master wc -l /var/lib/barrier/barrier@ip-of-master/barrier/SSL/Fingerprints/TrustedServers.txt 1 /var/lib/barrier/barrier@ip-of-master/barrier/SSL/Fingerprints/TrustedServers.txt ``` 6. Comment out ExexStartPre steps in barrierc@.service 7. Make sure changes are approved by systemd `systemctl daemon-reload` 8. Start service and check status ```sudo systemctl start barrierc@ip-of-master.service ➜ system sudo systemctl status barrierc@ip-of-master.service --no-pager --full ● barrierc@ip-of-master.service - Barrier Client connected to ip-of-master (Open-source KVM software) Loaded: loaded (/usr/local/lib/systemd/system/barrierc@.service; enabled; vendor preset: enabled) Active: failed (Result: core-dump) since Wed 2020-06-03 21:19:13 CEST; 3s ago Docs: man:barrierc(1) man:barriers(1) https://github.com/debauchee/barrier/wiki Process: 9270 ExecStart=/usr/local/bin/barrierc --enable-crypto --display ${DISPLAY} --debug ${LOG_LEVEL} --no-daemon ip-of-master (code=dumped, signal=ABRT) Main PID: 9270 (code=dumped, signal=ABRT) jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Main process exited, code=dumped, status=6/ABRT jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Failed with result 'core-dump'. jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Scheduled restart job, restart counter is at 5. jun 03 21:19:13 hostname-of-client systemd[1]: Stopped Barrier Client connected to ip-of-master (Open-source KVM software). jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Start request repeated too quickly. jun 03 21:19:13 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Failed with result 'core-dump'. jun 03 21:19:13 hostname-of-client systemd[1]: Failed to start Barrier Client connected to ip-of-master (Open-source KVM software). ``` ### Other info ### core dump: [core.barrierc.0.fe76b36acc64456b893a583eb3c1ae9f.9270.1591211953000000000000.zip](https://github.com/debauchee/barrier/files/4725765/core.barrierc.0.fe76b36acc64456b893a583eb3c1ae9f.9270.1591211953000000000000.zip)
Author
Owner

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

<!-- gh-comment-id:638412802 --> @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.
Author
Owner

@simons-public commented on GitHub (Jun 6, 2020):

@jmartens is this the same issue as #733?

<!-- gh-comment-id:639942327 --> @simons-public commented on GitHub (Jun 6, 2020): @jmartens is this the same issue as #733?
Author
Owner

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

<!-- gh-comment-id:640067801 --> @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.
Author
Owner

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

use a relatively small hack to keep barriers/barrierc from crashing on
unixes when they are killed from the GUI with QProcess's close(). the
stdin stream is going completely unused (though the stdout stream is
not) so use stdin to send a shutdown command. this solution avoids all
the nastiness and overhead of using shared memory, mutexes, condvars,
etc. just to communicate "stop" from one process to another

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 barrierc being run as a systemd service.

<!-- gh-comment-id:683523186 --> @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: https://github.com/debauchee/barrier/blob/5a02070b54205f8441f749c454465e7ef7fb5afa/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: > use a relatively small hack to keep barriers/barrierc from crashing on > unixes when they are killed from the GUI with QProcess's close(). the > stdin stream is going completely unused (though the stdout stream is > not) so use stdin to send a shutdown command. this solution avoids all > the nastiness and overhead of using shared memory, mutexes, condvars, > etc. just to communicate "stop" from one process to another 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 `barrierc` being run as a systemd service.
Author
Owner

@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 the expect package.

Longer Version

So, on a hunch, I tried a few things and came up with a workaround! Wrapping the barrierc command in unbuffer from the expect package does some magic with

I 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, alasudo 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]:24800

Example 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

Description=Barrier xauth/display manager workaround 
Requires=display-manager.service
After=display-manager.service
StartLimitIntervalSec=0

[Service]
Type=oneshot
ExecStart=/bin/cp '/var/run/lightdm/root/:0' /tmp/000
ExecStart=/bin/chown geo: /tmp/000
User=root

[Install]
WantedBy=barrier.target

/etc/systemd/system/barrier.service

Description=Barrier mouse/keyboard share
Requires=barrier-pre.service
After=barrier-pre.service
StartLimitIntervalSec=0

[Service]
Type=simple
Environment=XAUTHORITY=/tmp/000
ExecStart=/usr/bin/unbuffer /usr/bin/barrierc -f --no-tray --no-restart --debug INFO --name arthur --enable-crypto --log /var/log/barrier/barrier2.log --display :0 [MYSERVERNAME]:24800
# Note - the line below will break this if you're expecting it to let you log in to an encrypted system
# Encryption workaround, untested as specifically written:
# Comment out the below line, and whe nyou're ready to log in, "ssh MYUSERNAME@MYCLIENT "sleep 120; rm /tmp/000" 
ExecStartPost=/bin/rm /tmp/000
Restart=always
RestartSec=10
User=MYUSERNAME

[Install]
WantedBy=multi-user.target```
<!-- gh-comment-id:743394005 --> @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 the `expect` package. ## Longer Version So, on a hunch, I tried a few things and came up with a workaround! Wrapping the `barrierc` command in `unbuffer` from the `expect` package does some magic with I 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]:24800``` ## Example 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 ```[Unit] Description=Barrier xauth/display manager workaround Requires=display-manager.service After=display-manager.service StartLimitIntervalSec=0 [Service] Type=oneshot ExecStart=/bin/cp '/var/run/lightdm/root/:0' /tmp/000 ExecStart=/bin/chown geo: /tmp/000 User=root [Install] WantedBy=barrier.target ``` ### /etc/systemd/system/barrier.service ```[Unit] Description=Barrier mouse/keyboard share Requires=barrier-pre.service After=barrier-pre.service StartLimitIntervalSec=0 [Service] Type=simple Environment=XAUTHORITY=/tmp/000 ExecStart=/usr/bin/unbuffer /usr/bin/barrierc -f --no-tray --no-restart --debug INFO --name arthur --enable-crypto --log /var/log/barrier/barrier2.log --display :0 [MYSERVERNAME]:24800 # Note - the line below will break this if you're expecting it to let you log in to an encrypted system # Encryption workaround, untested as specifically written: # Comment out the below line, and whe nyou're ready to log in, "ssh MYUSERNAME@MYCLIENT "sleep 120; rm /tmp/000" ExecStartPost=/bin/rm /tmp/000 Restart=always RestartSec=10 User=MYUSERNAME [Install] WantedBy=multi-user.target```
Author
Owner

@mirh commented on GitHub (Oct 7, 2021):

Does #694 fixes/improves this?

<!-- gh-comment-id:937797325 --> @mirh commented on GitHub (Oct 7, 2021): Does #694 fixes/improves this?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#575
No description provided.