Created attachment 216989 [details] xpra server log Xpra doesn't seem to work by default. Server log attached below. Paths like /var/run/user/1001/xpra and /var/run/xpra do not exist by default on FreeBSD. Starting xpra with xpra --socket-dir=/tmp on both the client and server makes it work. Apparently a default for this can be set at compile time.
Can you, please, check if creating /var/run/xpra directory with 0666 permission mode fixes the problem for you?
It appears not. The server log is identical to the one previously uploaded. The server does start, but the client can't find the session, not even when it is running on the same machine. Also, the /var/run/xpra/ directory remains empty at all times.
(In reply to Aram Hăvărneanu from comment #2) You still see 2020-08-03 11:54:21,948 Warning: failed to create socket directory '/var/run/xpra' 2020-08-03 11:54:21,948 [Errno 13] Permission denied: '/var/run/xpra' in the log? This is strange.
Sorry, user error, I created the directory on the wrong machine... Now with this: z800:aram$ ls -lad /var/run/xpra drw-rw-rw- 2 root wheel 2 Aug 19 10:50 /var/run/xpra I get this snippet in the log instead: 2020-08-19 11:14:47,351 cannot create group socket '/var/run/xpra/z800.mgk.ro-102' 2020-08-19 11:14:47,351 [Errno 13] Permission denied So I changed the permissions to 1777: z800:aram$ ls -lad /var/run/xpra drwxrwxrwt 2 root wheel 2 Aug 19 10:50 /var/run/xpra And now that message went away and was replaced with: 2020-08-19 11:21:07,667 created unix domain socket '/var/run/xpra/z800.mgk.ro-103' With this configuration the client can find the socket, and the programs works correctly: 2020-08-19 11:21:49,869 New unix-domain connection received 2020-08-19 11:21:49,870 on '/var/run/xpra/z800.mgk.ro-103' 2020-08-19 11:21:49,875 Handshake complete; enabling connection
A commit references this bug: Author: arrowd Date: Wed Aug 19 11:05:50 UTC 2020 New revision: 545311 URL: https://svnweb.freebsd.org/changeset/ports/545311 Log: x11/xpra: Create /var/run/xpra directory during installation. It is required by Xpra when no XDG_RUNTIME_DIR is available. PR: 248451 Changes: head/x11/xpra/Makefile head/x11/xpra/pkg-plist
Thanks for testing, fixed!
This fix is not correct because `/var/run` doesn't need to persist across reboots. A directory is going to need to be created at runtime.
(In reply to Duane from comment #7) > This fix is not correct because `/var/run` doesn't need to persist across reboots. A directory is going to need to be created at runtime. To approach the upstream with this problem I need a source of this information. Where is it stated that /var/run isn't a persistent location?
(In reply to Gleb Popov from comment #8) For FreeBSD, see https://www.freebsd.org/cgi/man.cgi?query=hier where it says "since it was booted". For Linux, see https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA where it says "Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process" The simplest solution could be to just change the `socket-dirs` variable in `/usr/local/etc/xpra/conf.d/10_network.conf` to use `/tmp` and/or `~/.xpra`. The `/var/run/user/$UID` path is a specific systemd directory which I doubt will ever be relevant on FreeBSD. The `/var/run/xpra` directory would be worth using with an Xpra proxy service but then that should be managed by an rc script which would create the directory on start.
A commit references this bug: Author: arrowd Date: Wed Dec 9 13:56:34 UTC 2020 New revision: 557374 URL: https://svnweb.freebsd.org/changeset/ports/557374 Log: x11/xpra: Update to 4.0.5. Do not create /var/run/xpra directory during package installation, because /var/run isn't a persistent location. PR: 248451 Changes: head/x11/xpra/Makefile head/x11/xpra/distinfo head/x11/xpra/files/patch-xpra_platform_xposix_paths.py head/x11/xpra/pkg-plist
In the new version of the port I removed /var/run/xpra directory creation. However, I also pulled in following patch from upstream: http://xpra.org/trac/changeset/28004/xpra Aram, can you confirm that things are still working for you?