bwrap: Can't find source path /tmp/.X11-unix/X0: No such file or directory

[ventsin]

Your system information

• Steam Runtime Version: 1642451672
• Distribution (e.g. Ubuntu 18.04): Artix KDE s6
• Link to your full system information (Help -> System Information) in a Gist
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Proton 5.13+
• If you are using Steam Linux Runtime, or Proton 5.13 or newer: What versions are listed in SteamLinuxRuntime_soldier/VERSIONS.txt?

depot	0.20211209.37			# Overall version number
pressure-vessel	0.20211207.0			
scripts	v0.20211029.0-0-g2d89be4			# Entry point scripts, etc.
soldier	0.20211207.0	soldier	0.20211207.0	# soldier_platform_0.20211207.0/

Please describe your issue in as much detail as possible:

I can't launch any games with Proton 5.13+. I just wait for the "Preparing to launch game..." window to close and then the play button goes green again and nothing happens.
Based on my searches so far, I'm convinced this is a bubblewarp issue. Yet installing bubblewrap-suid or setting kernel.unprivileged_userns_clone=1 doesn't change anything. This is the log from when I try to launch a game.

Steps for reproducing this issue:

1. Launch any game through Proton 5.13+.
2. Wait for "Preparing to launch game..." window to close.
3. Nothing happens.

[smcv]

It looks like something involving X11 is not working the way it should. The container setup code (pressure-vessel) needs to share the X11 socket with the container so that the game can display its window. Your DISPLAY environment variable is set to :0, so this means we try to use a socket /tmp/.X11-unix/X0; but apparently that doesn't exist on your system.

What is the output of ls -al /tmp/.X11-unix on this system?

How are X11 and /tmp set up on Artix? Do you know about anything that is particularly unusual on this OS?

In particular, is the X11 server configured to only work via TCP (AF_INET) sockets, and not via AF_UNIX sockets? Or is there something unusual about /tmp, like maybe a polyinstantiated setup? Or does Artix reconfigure or patch the X11 server and client libraries to use a different directory instead of /tmp/.X11-unix, or a different socket?

Or are you running Steam inside some sort of container or LSM confinement?

This is the log from when I try to launch a game.

Was this log collected with any special workarounds, for example installing bubblewrap-suid or altering the value of kernel.unprivileged_userns_clone, already in use?

Based on my searches so far, I'm convinced this is a bubblewarp issue

From the error message at the end of your log, it looks like this is not directly a bubblewrap issue, but more like a problem with the arguments that pressure-vessel is passing to bubblewrap to create its container.

But for your information:

pressure-vessel has the same user namespace requirements as Flatpak. The unprivileged bubblewrap configuration is what I would recommend: it is the most likely to continue to work in future versions of Steam, and is also needed by container frameworks like Podman, and by the sandboxing mechanisms in some web browsers. You shouldn't need to install bubblewrap-suid if you have kernel.unprivileged_userns_clone=1.

Conversely, the setuid bubblewrap configuration is also something that should work, although I wouldn't recommend it. You don't need to set kernel.unprivileged_userns_clone=1 if you are using bubblewrap-suid.

[ventsin]

What is the output of ls -al /tmp/.X11-unix on this system?

As follows:

total 0
drwxrwxrwt 2 root root  40 jan 25 11:45 .
drwxrwxrwt 9 root root 260 jan 25 11:45 ..

Which confuses me, since /tmp/.X11-unix/X0 seems to exist, from the output of sudo lsof -p $(pidof Xorg) | grep unix:

Xorg    1197 root    5u     unix 0x000000005b595654      0t0      17499 @/tmp/.X11-unix/X0 type=STREAM (LISTEN)
Xorg    1197 root    6u     unix 0x000000002ebc1c31      0t0      17500 /tmp/.X11-unix/X0 type=STREAM (LISTEN)
Xorg    1197 root    7u     unix 0x000000002feb10bc      0t0      26468 @/tmp/.X11-unix/X0 type=STREAM (CONNECTED)
Xorg    1197 root    9u     unix 0x00000000a3bb9879      0t0      17502 type=STREAM (CONNECTED)
Xorg    1197 root   12u     unix 0x00000000ce2820cb      0t0      15717 type=STREAM (CONNECTED)
Xorg    1197 root   17u     unix 0x000000005190bbf3      0t0      17652 @/tmp/.X11-unix/X0 type=STREAM (CONNECTED)
Xorg    1197 root   22u     unix 0x00000000cdf14dc5      0t0      15728 @var/run/nvidia-xdriver-5868ed5b@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ type=DGRAM (CONNECTED)
Xorg    1197 root   24u     unix 0x000000008367c2ee      0t0      15729 /var/run/nvidia-xdriver-5868ed5b type=DGRAM (UNCONNECTED)
Xorg    1197 root   27u     unix 0x000000005da7e1d3      0t0      15730 type=STREAM (CONNECTED)
Xorg    1197 root   49u     unix 0x0000000045a684cb      0t0      26457 @/tmp/.X11-unix/X0 type=STREAM (CONNECTED)
...

There are many more lines similar to the last one.

How are X11 and /tmp set up on Artix? Do you know about anything that is particularly unusual on this OS?

As far as I'm aware Artix is just Arch Linux but with different init systems, in this case, S6. I'm not well versed in X11 configuration, but I'll try my best to provide any info you need.

I ran strings /usr/lib*/libxcb.so|grep X11 to see if the directory was patched, but it doesn't seem like it:

/tmp/.X11-unix/X

Or are you running Steam inside some sort of container or LSM confinement?

No, Steam was installed from the Arch repositories with pacman -S steam and ran directly as steam.

Was this log collected with any special workarounds, for example installing bubblewrap-suid or altering the value of kernel.unprivileged_userns_clone, already in use?

The log was collected with both workarounds in use. I tried everything separately and I'm 100% sure the line bwrap: Can't find source path /tmp/.X11-unix/X0: No such file or directory has been a constant before, during and after any workarounds.

For now this is the information I can provide. I'll try to setup everything according to the unpriviledged bubblewrap section and if I make any progress I'll update this thread.

[smcv]

I tried everything separately and I'm 100% sure the line bwrap: Can't find source path /tmp/.X11-unix/X0: No such file or directory has been a constant before, during and after any workarounds.

OK, thanks for confirming this.

The setuid vs. unprivileged status of bwrap is not going to affect the failure mode that results in this error message, and I think in fact it will fail with this error message before the setuid vs. unprivileged status of bwrap becomes relevant to you.

What is the output of ls -al /tmp/.X11-unix on this system?

[it's empty]

This is strange. It looks as though Xorg has successfully listened on the socket /tmp/.X11-unix/X0, but then something else has subsequently come along and deleted that socket from the filesystem. Unix filesystem semantics say you can continue to have a file open even if it has been deleted, so that works, but is not practically useful because X11 clients can no longer connect to it.

The rest of your X11 clients are presumably connecting to @/tmp/.X11-unix/X0, which is an "abstract" Unix socket that does not exist in the filesystem, and passes across container boundaries as though it was a localhost TCP socket (so it is shared with any container that does not enter a new network namespace, which pressure-vessel doesn't do).

This seems like it is probably not what you intended to happen, and I would suggest you look into what could be deleting the socket: might you perhaps be using tmpreaper or a similar program in a configuration that is more aggressive than you intended?

But I think pressure-vessel (and Flatpak, which is where we got this code) could cope with this better, so I'll try to implement that.

[smcv]

flatpak/flatpak#4706 should resolve the equivalent of this in Flatpak.

I'd be interested to know why this socket went missing...

[ventsin]

Honestly, I'm dumbfounded here. tmpreaper isn't installed, and I haven't been able to find any info on how /tmp could be being cleaned up. No cronjobs, nothing. This is a really fresh install of Artix and Steam was pretty much the first thing I tried to do, aside from enabling the Arch repositories.

I'll keep trying to figure this out tonight and see if anything comes up.

Thanks for everything, though!

[ventsin]

What I managed to isolate to so far is that whatever is deleting X0 is doing so when the computer boots.
Logging out and in again had X create a new socket, and this is time it stayed there.

I was able to launch Deep Rock Galactic just fine this time. I'll keep on investigating.

[smcv]

The beta versions of Steam Linux Runtime - soldier and Steam Linux Runtime - sniper are more robust against this, by using the abstract socket if the filesystem-based socket does not exist. To check whether you have this change, look at SteamLinuxRuntime_soldier/VERSIONS.txt, and SteamLinuxRuntime_sniper/VERSIONS.txt if present. The line that is significant for this particular issue is the one that mentions pressure-vessel, and the workaround is present in pressure-vessel 0.20220131.0 or later.

How to use a beta runtime

The default versions of Steam Linux Runtime - soldier and Steam Linux Runtime - sniper do not yet have this change, but are likely to pick it up at some point in the future if there are no reports of regressions.

What I managed to isolate to so far is that whatever is deleting X0 is doing so when the computer boots.

I think this is a bug in either your local configuration or your operating system, and I am not able to help you find the root cause. Your operating system's support channels might be able to help you with this.

If you do manage to find out what is going on, I'd be interested to know!

The newer versions of pressure-vessel mentioned above should be able to work around this for you, so after upgrading pressure-vessel it shouldn't be a practical problem for your Proton games any more, even if you are unable to find out why this is happening.

[smcv]

Several Artix users reported similar symptoms on ValveSoftware/Proton#5340, so I suspect this might be a more general Artix bug, rather than misconfiguration on your specific machine.

[smcv]

@MichaelAllenHardeman reported this to the Artix forums: https://forum.artixlinux.org/index.php/topic,3628.0.html

@Blisto91 also mentioned a matching error message on ValveSoftware/Proton#5340.

As a note for people who are not sure whether they are seeing this issue or something different, there is nothing particularly special about 0 here. If your X11 display happens to have a larger number than :0, then the sockets involved will be different. For example, if you have DISPLAY=:42, then that uses filename /tmp/.X11-unix/X42 and abstract socket address @/tmp/.X11-unix/X42 to communicate with the X server. The display number that is used in practice will depend on how your X server was started (gdm, lightdm, xdm, startx, etc.) and how many X sessions there have been since system startup.

In recent OS designs that support namespace-based sandboxing and containers, the filesystem-based sockets like /tmp/.X11-unix/X0 are generally considered to be preferable to the abstract sockets like @/tmp/.X11-unix/X0. This is because container technologies like Docker, lxc and Flatpak are able to control whether each filesystem socket is shared with the container or not, individually, which is better for privilege-separation. The abstract sockets are linked to network namespaces, so the only options are to share all of them or none of them, with no ability to do something in between.

As for the root cause for the socket being deleted, if I was a developer of the affected operating system, the places I would be starting to look would be anything that is designed to delete unused files from /tmp. For instance, perhaps there might be an opentmpfiles configuration file in tmpfiles.d that is too eager to delete things?

Anything that changes how /tmp works, such as libpam-tmpdir, could be another place to start looking.

[michael-hardeman]

It seems to be a mis-configuration on my part. I use OpenRC as my init system and I had lightdm set to the boot runlevel. This might have been causing a race with xserver. I changed lightdm to default runlevel and it seems to create /tmp/.X11-unix/X0 correctly.

[Blisto91]

My memory is quite bad so sorry for not remembering much 😁.
I don't think i was actually able to repro the issue myself (tho maybe i misremember) i just looked at @MichaelAllenHardeman's log and this line stuck out

bwrap: Can't find source path /tmp/.X11-unix/X0: No such file or directory

So i did some googling and remember finding it or similar mentioned by flatpak users and maybe some other stuff.
So I'm probably not much help here 🙂