github-starred/barrier

Fork 0

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

mkdir -p ${FP_DIR} #576

New issue

Open

opened 2026-05-05 06:42:26 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 06:42:26 -06:00

Owner

Originally created by @jmartens on GitHub (Jun 3, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/733

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

Build using CMAKE install target set to for example /usr/local
make install
sudo systemctl start barrierc@ip-of-master.service
observe start failure:

Job for barrierc@ip-of-master.service failed because the control process exited with error code.
See "systemctl status barrierc@ip-of-master.service" and "journalctl -xe" for details.

check why:

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: exit-code) since Wed 2020-06-03 20:59:03 CEST; 11s ago
       Docs: man:barrierc(1)
             man:barriers(1)
             https://github.com/debauchee/barrier/wiki
    Process: 8869 ExecStartPre=/usr/bin/mkdir -p ${FP_DIR} (code=exited, status=203/EXEC)

jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Control process exited, code=exited, status=203/EXEC
jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Failed with result 'exit-code'.
jun 03 20:59:03 hostname-of-client systemd[1]: Failed to start Barrier Client connected to ip-of-master (Open-source KVM software).
jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Scheduled restart job, restart counter is at 5.
jun 03 20:59:03 hostname-of-client systemd[1]: Stopped Barrier Client connected to ip-of-master (Open-source KVM software).
jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Start request repeated too quickly.
jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Failed with result 'exit-code'.
jun 03 20:59:03 hostname-of-client systemd[1]: Failed to start Barrier Client connected to ip-of-master (Open-source KVM software).

Originally created by @jmartens on GitHub (Jun 3, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/733 ### 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 ### 1. Build using CMAKE install target set to for example /usr/local 2. `make install` 3. `sudo systemctl start barrierc@ip-of-master.service` 4. observe start failure: ``` Job for barrierc@ip-of-master.service failed because the control process exited with error code. See "systemctl status barrierc@ip-of-master.service" and "journalctl -xe" for details. ``` 5. check why: ``` 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: exit-code) since Wed 2020-06-03 20:59:03 CEST; 11s ago Docs: man:barrierc(1) man:barriers(1) https://github.com/debauchee/barrier/wiki Process: 8869 ExecStartPre=/usr/bin/mkdir -p ${FP_DIR} (code=exited, status=203/EXEC) jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Control process exited, code=exited, status=203/EXEC jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Failed with result 'exit-code'. jun 03 20:59:03 hostname-of-client systemd[1]: Failed to start Barrier Client connected to ip-of-master (Open-source KVM software). jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Scheduled restart job, restart counter is at 5. jun 03 20:59:03 hostname-of-client systemd[1]: Stopped Barrier Client connected to ip-of-master (Open-source KVM software). jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Start request repeated too quickly. jun 03 20:59:03 hostname-of-client systemd[1]: barrierc@ip-of-master.service: Failed with result 'exit-code'. jun 03 20:59:03 hostname-of-client systemd[1]: Failed to start Barrier Client connected to ip-of-master (Open-source KVM software). ```

gitea-mirror commented

2026-05-05 06:42:28 -06:00

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.

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

gitea-mirror commented

2026-05-05 06:42:30 -06:00

Author

Owner

@jmartens commented on GitHub (Jun 6, 2020):

I am not sure if the complete path to executables are realy required as ExecStartPre=+mkdir -p "${FP_DIR} and ExecStartPre=+sh -c "[ -f "${FP_DIR}/TrustedServers.txt" ] ||\ ... seems to work for me on Ubuntu 20.04 LTS apart from that other executables like openssl also are not referenced using the full path:

    Process: 17961 ExecStartPre=/bin/mkdir -p ${FP_DIR} (code=exited, status=0/SUCCESS)
    Process: 17970 ExecStartPre=/bin/sh -c [ -f ${FP_DIR}/TrustedServers.txt ] || openssl s_client -connect ip-of-master:24800 2>/dev/null | openssl x509 -noout -sha1 -fingerprint | grep -oE '([A-Z0-9]{2}:?){20}' > ${FP_DIR}/TrustedServers.txt (code=exited, status=0/SUCCESS)

At least on my system there is not /usr/bin/mkdir, mine is in /bin/

I added the + sign to the commands as PermitRootLogin is deprecated and this is the new method to allow elevation, see systemd docs for ExecStart

@jmartens commented on GitHub (Jun 6, 2020): I am not sure if the complete path to executables are realy required as `ExecStartPre=+mkdir -p "${FP_DIR}` and `ExecStartPre=+sh -c "[ -f "${FP_DIR}/TrustedServers.txt" ] ||\ ...` seems to work for me on Ubuntu 20.04 LTS apart from that other executables like openssl also are not referenced using the full path: ``` Process: 17961 ExecStartPre=/bin/mkdir -p ${FP_DIR} (code=exited, status=0/SUCCESS) Process: 17970 ExecStartPre=/bin/sh -c [ -f ${FP_DIR}/TrustedServers.txt ] || openssl s_client -connect ip-of-master:24800 2>/dev/null | openssl x509 -noout -sha1 -fingerprint | grep -oE '([A-Z0-9]{2}:?){20}' > ${FP_DIR}/TrustedServers.txt (code=exited, status=0/SUCCESS) ``` At least on my system there is not /usr/bin/mkdir, mine is in /bin/ I added the + sign to the commands as PermitRootLogin is deprecated and this is the new method to allow elevation, see [systemd docs for ExecStart](https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart=)

gitea-mirror commented

2026-05-05 06:42:31 -06:00

Author

Owner

@shymega commented on GitHub (Jun 6, 2020):

Agreed. We need to ensure portability.. whilst absolute paths to executables are - to me, preferable on my own systems - for a varying range of distros that Barrier supports, we should avoid absolute paths.

@shymega commented on GitHub (Jun 6, 2020): Agreed. We need to ensure portability.. whilst absolute paths to executables are - to me, preferable on my _own systems_ - for a varying range of distros that Barrier supports, we should avoid absolute paths.

gitea-mirror commented

2026-05-05 06:42:33 -06:00

Author

Owner

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

@jmartens @shymega I replaced the mkdir commands with StateDirectory as recommended in the PR thread. With that change the only relative path should be /bin/sh. Unfortunately older versions of systemd don't support relative paths so it's kind of a necessity here, but /bin/sh should exist on any reasonable system.

Adding + to the /bin/sh command shouldn't be necessary anymore with StateDirectory since it sets permissions.

@simons-public commented on GitHub (Jun 6, 2020): @jmartens @shymega I replaced the `mkdir` commands with StateDirectory as recommended in the PR thread. With that change the only relative path should be `/bin/sh`. Unfortunately older versions of systemd don't support relative paths so it's kind of a necessity here, but `/bin/sh` should exist on any reasonable system. Adding `+` to the `/bin/sh` command shouldn't be necessary anymore with StateDirectory since it sets permissions.

gitea-mirror commented

2026-05-05 06:42:36 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 20, 2020):

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions[bot] commented on GitHub (Sep 20, 2020): This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

gitea-mirror commented

2026-05-05 06:42:38 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

@simons-public Should this bug still be open? I'm trying to figure out whether the bot closed this bug unnecessarily.

@p12tic commented on GitHub (Jan 10, 2021): @simons-public Should this bug still be open? I'm trying to figure out whether the bot closed this bug unnecessarily.

gitea-mirror commented

2026-05-05 06:42:39 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

Let's reopen so that it's not forgotten again. We can close anytime.

@p12tic commented on GitHub (Jan 10, 2021): Let's reopen so that it's not forgotten again. We can close anytime.