[5.0.4] xpra start --attach=yes (combining server and client) always fails to connect the client to the just-started server

[hartwork]

Describe the bug
Hi! 👋

xpra start --daemon=no --attach=yes always fails to connect the client to the just-started server:

# xpra --version
[..]
xpra v5.0.4-r0

# xpra start --daemon=no --attach=yes
[..]
server socket for display 1 not found
 waiting up to 20 seconds
Warning: failed to connect:
 cannot find live server for display 1
[..]
2023-12-17 03:53:53,547 removing unix domain socket '/run/user/1000/xpra/clients/host123-19384'

Or:

# xpra --version
xpra v4.4.6-r2

# xpra start --daemon=no --attach=yes
[..]
server socket for display :1 not found

 waiting up to 20 seconds

[..]
Warning: failed to connect:

 cannot find live server for display :1

2023-12-17 03:52:26,870 removing unix domain socket '/run/user/1000/xpra/clients/host123-19168'

What does work is using xpra start and xpra attach separately, e.g.:

xpra start --daemon=no --attach=no --bind=/tmp/xpra123 &
while ! test -e /tmp/xpra123 ; do sleep 0.5 ; done
xpra attach /tmp/xpra123

To Reproduce
Run xpra start --daemon=no --attach=yes

System Information (please complete the following information):

• Server OS: Linux
• Client OS: Linux
• Xpra Server Version: 5.0.4
• Xpra Client Version: 5.0.4

Additional context
n/a

[totaam]

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

[hartwork]

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.

[hartwork]

[..] I'll probably make it use xpra id then.

Done: hartwork/sandwine#43

[hartwork]

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.

[totaam]

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.

[hartwork]

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 same socket-dirs.

I'll investigate more, it's got to be something 😃

[hartwork]

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?

[totaam]

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

[hartwork]

$ 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?

[totaam]

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'>

[hartwork]

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?

[hartwork]

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

[totaam]

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.

[hartwork]

@totaam I understand and respect that decision.

[totaam]

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.

[hartwork]

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

[totaam]

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.