Comments (17)
Which seems to mean that it does not affect the client and server equally?
Probably.
But since this is the result of modifying the default settings, I'm not going to worry about it too much for now.
from xpra.
What exact distribution can I reproduce this on?
Which packages were installed?
What is in your server log?
while ! test -e /tmp/xpra123
This may or may not work.
The proper test is to run something like xpra id /tmp/xpra123
as this will verify that the server can accept connections.
Incidentally, that's what --attach=yes
does.
Works-for-me(tm).
from xpra.
Hi @totaam,
thanks for your quick reply!
What exact distribution can I reproduce this on?
Sorry for being shy on that end, I did it out of experience with other upstreams, this is on Gentoo Linux.
Which packages were installed? What is in your server log?
For 4.x.x it was system package x11-wm/xpra-4.4.6-r2
, for 5.x.x it was a local virtualenv from Git off tag v5.0.4.
while ! test -e /tmp/xpra123
This may or may not work. The proper test is to run something like
xpra id /tmp/xpra123
as this will verify that the server can accept connections.
Interesting! I'm assuming by "mar or may not work" you mean that the socket file could already be in place but not fully ready to connect to?
I added experimental support for (nested X11 using) Xpra to my Open Source Wine-on-Linux sandbox "sandwine" at hartwork/sandwine#39 the other day, I'll probably make it use xpra id
then.
Incidentally, that's what
--attach=yes
does. Works-for-me(tm).
I guess that means it would be good if I found the cause myself. My guess is that Xpra is giving up too early, but we'll see. I hope I can figure it out.
from xpra.
[..] I'll probably make it use
xpra id
then.
Done: hartwork/sandwine#43
from xpra.
Incidentally, that's what
--attach=yes
does. Works-for-me(tm).
@totaam further investigation shows that dotxpra.get_display_state(display)
keeps returning SocketState.DEAD
because DotXpra.get_display_state
is probing a different socket for the client than then server is actually using:
- actual:
/run/user/<uid>/xpra/clients/<hostname>-<number>
- probed:
/run/xpra/<display>/[..]
Once I append --socket-dirs=/tmp/dirs --socket-dir=/tmp/dir
— which makes xpra start --daemon=no --attach=yes --socket-dirs=/tmp/dirs --socket-dir=/tmp/dir
in full — things start to work, but it's only a workaround. Does that make sense?
PS: This was with commit 6e7fe1a on master
.
from xpra.
actual:
/run/user/<uid>/xpra/clients/<hostname>-<number>
That's the client socket, this is not used for connecting to a server.
/run/xpra/<display>/[..]
That's only used if you're a member of the xpra
group.
The client and server share the same command line invocation, so they should be using the same arguments to dotxpra
and therefore the same socket-dirs
.
from xpra.
actual:
/run/user/<uid>/xpra/clients/<hostname>-<number>
That's the client socket, this is not used for connecting to a server.
@totaam my bad, I'm rather new to Xpra.
/run/xpra/<display>/[..]
That's only used if you're a member of the
xpra
group.
Cannot confirm, I'm not in that group (but the group exists) and that path value was obtained using print
from inside get_display_state
. This is real 😃
The client and server share the same command line invocation, so they should be using the same arguments to
dotxpra
and therefore the samesocket-dirs
.
I'll investigate more, it's got to be something 😃
from xpra.
actual:
/run/user/<uid>/xpra/clients/<hostname>-<number>
That's the client socket, this is not used for connecting to a server.
@totaam second try, this is what's happening:
- Both the server and client start out with options:
'socket_dirs': ['/run/xpra']
'socket_dir': ''
'sessions_dir': '$XDG_RUNTIME_DIR/xpra'
.
- The server starts listening at
/run/user/<uid>/xpra/<display>/socket
(more on that below). - The client is probing
/run/xpra/<display>/[..]
. - (Directory
/run/xpra/<display>/
does not exist.) - (Directory
/run/xpra/
is not writable, see below).
The code that makes the server pick /run/user/<uid>/xpra/<display>/socket
is this:
def setup_local_sockets(bind, socket_dir:str, socket_dirs, session_dir:str,
display_name:str, clobber,
mmap_group:str="auto", socket_permissions:str="600", username:str="",
uid:int=0, gid:int=0) -> dict[Any, Callable]:
[..]
try:
[..]
for b in bind:
[..]
if sockpath=="auto":
[..]
if session_dir and not WIN32:
session_socket = os.path.join(session_dir, "socket")
sockpaths[session_socket] = options
[..] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The client fails to do the same and only looks at /run/xpra/<display>/[..]
where there is nothing to be found, hence the mismatch and hence --socket-dirs=/tmp/dirs --socket-dir=/tmp/dir
makes things work.
Regarding permissions:
# ls -dl /run/xpra
drwxrwxr-t 3 root xpra 60 Dez 18 14:47 /run/xpra
# groups | grep xpra
<no output>
Regarding XDG_RUNTIME_DIR
:
# echo "${XDG_RUNTIME_DIR}"
/run/user/1000
I hope that should be convincing that --attach=yes
does have a client-server-mismatch problem. What do you think?
from xpra.
$ xpra showconfig | grep socket-dirs
client-socket-dirs = '/run/user/1000/xpra/clients'
socket-dirs = '/run/user/1000/xpra', '/run/xpra', '~/.xpra'
If both client and server use these settings, /run/xpra
is irrelevant and it should find the sockets.
from xpra.
$ xpra showconfig | grep socket-dirs client-socket-dirs = '/run/user/1000/xpra/clients' socket-dirs = '/run/user/1000/xpra', '/run/xpra', '~/.xpra'If both client and server use these settings,
/run/xpra
is irrelevant and it should find the sockets.
@totaam but they don't:
# xpra showconfig | grep socket-dirs
Warning: invalid option: 'dbus-proxy'
Warning: invalid option: 'fake-xinerama'
Warning: invalid packet encoder(s) specified: rencode, bencode, yaml
client-socket-dirs = '/run/user/1000/xpra/clients'
socket-dirs (used) = '/run/xpra' <class 'list'>
socket-dirs (default) = '/run/user/1000/xpra', '/run/xpra', '~/.xpra' <class 'list'>
# xpra --version
Warning: invalid option: 'dbus-proxy'
Warning: invalid option: 'fake-xinerama'
xpra v6.0-r2888
# git rev-parse HEAD
9612a5bc4468c7a6d7066d67378c1fbc8e79460a
How would you like to continue?
from xpra.
You clearly have some old config files that don't match the version of the code you're running.
So, you've changed the default config?
socket-dirs (used) = '/run/xpra' <class 'list'>
socket-dirs (default) = '/run/user/1000/xpra', '/run/xpra', '~/.xpra' <class 'list'>
from xpra.
You clearly have some old config files that don't match the version of the code you're running.
So, you've changed the default config?
socket-dirs (used) = '/run/xpra' <class 'list'> socket-dirs (default) = '/run/user/1000/xpra', '/run/xpra', '~/.xpra' <class 'list'>
I have not changed anything manually, there is file ~/.config/xpra/xpra.conf
apparantly, but it's all commented out (not by me, didn't touch the file):
$ cat ~/.config/xpra/xpra.conf
# xpra user configuration file
# place your custom settings in this file
# they will take precedence over the system default ones.
# Examples:
# speaker=off
# dpi=144
# For more information on the file format,
# see the xpra manual at:
# https://github.com/Xpra-org/xpra/tree/master/docs/
@totaam I wrote a detailed analysis of what is happening and why at #4077 (comment) — did you see that analysis?
from xpra.
@totaam I now found this:
# grep '^[^#].*/run/xpra' /etc/xpra/conf.d/10_network.conf
socket-dirs = /run/xpra
Once I comment out that line, --attach=yes
starts working. Which seems to mean that it does not affect the client and server equally?
from xpra.
@totaam I understand and respect that decision.
from xpra.
Closing as this is not a bug: I cannot reproduce this with a valid config.
If your configuration does not include at least one valid socket-dir
, then obviously the client won't be able to connect to this server.
from xpra.
@totaam I have a hard time agreeing to that evaluation since the bug is that client and server behavior are not in sync, I have proven that they are not, that's the bug and it is a bug.
from xpra.
that's the bug and it is a bug.
There are a million ways to break things by using invalid options in your configuration.
You found one of many.
Please use a valid configuration. xpra needs at least one valid socket directory so that clients can connect to it.
In the future, it may be possible to workaround this problem using abstract sockets: #4098, but those are not discoverable so you would not be able to connect again without knowing the display number.
from xpra.
Related Issues (20)
- Connecting to an Xpra host using a Microsoft Surface Book detaches tablet from dock HOT 2
- Failing to set encoding h264: object has no attribute 'check_randr' HOT 2
- NameError: name 'get_default_port' is not defined. Did you mean: 'get_defaults'? HOT 2
- Failure to build xpra without nvcc HOT 2
- don't start `ibus-daemon` again HOT 1
- Windows 7 "SystemError: Negative size passed to PyUnicode_New" HOT 6
- `_ctypes.COMError: (-2147467262, 'Such connection is not supported', (None, None, None, 0, None))` HOT 2
- read-only buffers and `memoryview`s HOT 1
- cython build error `PyMemoryView_CheckExact` on MS Windows HOT 1
- Xpra Maximized windows change dimension as soon as focus change HOT 6
- GCC 14 - incompatible pointer types HOT 2
- At shadow start, the connection is "somehow shaky" HOT 2
- Weird args re-connection issue: `too many arguments to choose a display` HOT 7
- shadow: Maximizing a 1920x1080 on a 1920x1080 display creates "weird artifacts" HOT 2
- Is https://xpra.org/manual broken? HOT 3
- Tray Icon > About dialog doesn't open HOT 4
- Try to avoid removing `xpra/<screen>/` on destroy HOT 8
- xpra repos fail with CentOS 7 HOT 3
- (In)Release file out of date for the beta/jammy repo HOT 1
- systemd[39455]: xpra.socket: Failed to create listening socket ([::]:14500): Address already in use HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xpra.