Cannot Start Flatpak Apps Due To Missing /tmp/.X11-unix/X1 Source Path #938
Comments
|
Same error here with Ubuntu 16.04. |
|
Is there any information on the reason or even a workaround available? |
|
I just reboot the system, and then everything works. |
|
Switch to a different tvt and log in then Flatpaks would stop working again
and you would require another reboot. I'm not really sure what's happening
but it has to do with unix sockets.
…On Tue, Nov 28, 2017, 3:50 PM Jack Liu ***@***.***> wrote:
I just reboot the system, and then everything works.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#938 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEfnYCMEBF1rJ55il5o18lE4tPaAuOMvks5s7A-3gaJpZM4OnUKD>
.
|
|
I believe you have an issue with something periodically cleaning up the /tmp directory, removing the X socket. Other X apps may still work by using the abstract X socket, but that is not possible for flatpak to use. |
|
Rebooting is not an option for me. Is there any way to reconstruct the missing file? |
|
You don't have to reboot, but I don't think it is possible to tell the xserver to listen to a new socket, so you have to log out + log in. |
|
Also, you should go over your tmpwatches and make sure they don't remove stuff in /tmp/.X11-unix |
|
@clefebvre this seems to be a mint issue. You probably have some tmpfile cleaning script that removes old files, and its hitting the X socket files which is bad. It works for non-flatpak apps because the abstract socket path is not removed so clients fall back io it, but that one doesn't work in flatpaks. |
|
It seems a bit optimistic to rely on some file in /tmp never being deleted. |
|
The problem is that it is a unix domain socket. one that is deleted you can't recreate it. I mean, you can create a new one in the same spot, but the Xserver will not be listening to connections to the new one. For wayland this is better, because the wayland socket is in /run/user. |
|
And i agree that it is a bit optimistic to rely on files in /tmp, but the X11 design is from the 80s... |
|
hi @alexlarsson, I'm not aware of any scripts or job cleaning up /tmp, at least not out of the box. I assume this is added by a tool/package users have in common here. It seems to affect Mint but also Xenial and Fedora 26. Can people list their cron jobs and running processes so we can see what everyone has in common? |
|
Here's the list of running processes on my system (Fedora 27): As for cron jobs: |
|
I believe on newer systems this is handled by systemd-tmpfiles. Do you have anything in /etc/tmpfiles.d ? |
|
On fedora this seems to be in /usr/lib/tmpfiles.d/tmp.conf |
|
@poettering does this line in /usr/lib/tmpfiles.d/x11.conf Mean that the sockets in |
|
@alexlarsson We have code in tmpfiles that explicitly checks /proc/net/unix before we remove any AF_UNIX device nodes: https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c#L376 Of course, strictly speaking this is racy, but this is unlikely to be an issue IRL. At least I never heard of that. Hence, yes, the "10d" will cause aging, but /proc/net/unix should exclude it from that. Note that this logic is easily confused though: if you create an AF_UNIX node, and then rename it, then /proc/net/unix will show the old name, and hence the new name might be aged out by tmpfiles. Hence, doing "atomic" prepare-and-rename stuff with AF_UNIX is not gonna work. |
|
I'm running Linux Mint 19.1 and this is still happening. I don't have tmpwatch installed, nor do I have anything in /etc/tmpfiles.d. I have no cron jobs running that should wipe /tmp. This problem didn't happen for me on Linux Mint 18.3. |
|
It also doesn't happen with any other X program i know about. |
|
@torpak non-flatpak apps typically use the X11 abstract socket name which is not tmp-cleaned. Unfortunately that doesn't work for flatpak due to how network namespaces work, so flatpaked apps use the real on-filesystem socket. |
|
I just randomly saw this on a non-NVIDIA, mostly vanilla Fedora 31 Silverblue system. It's only been booted for around an hour or two, so I doubt tmpfiles ran...
Out of curiosity, could an socat-like approach work here? E.g. forward the abstract socket name to a socket path that's private to a Flatpak and then redirect that one inside? |
|
This seems like the same issue as #4702. If that's the case, then it should be fixed by flatpak 1.12.7 (and 1.13.1), to the extent that it can be fixed at all. If the app has and the app should continue to work. If the app does not have and the app will not work. Because abstract sockets are part of the network namespace, apps without
This would technically be implementable, but would be quite a lot of code to support something that is arguably already a broken system. More code means more bugs, so the Flatpak maintainers are not particularly keen to implement this. |
|
Proxying the socket (a socat-like approach) was discussed on #4706 but the conclusion was that we shouldn't. |
|
Unfortunately this doesn't seem to be fixed by 1.12.7 - I'm running 1.12.7 and still getting this issue. It doesn't log the error line (or at least I can't find it), but the app still doesn't start if |
|
@ermshiperete: Please try running it as
Do you mean "if |
|
The whole I tried running with Hmm, maybe that particular log message was in the log messages before starting the app? I didn't explicitly search for that. I'll try that next time it's happening - I rebooted and so currently don't have the problem. By the way, I don't have a |
In some cases, it's not possible to start Flatpak apps altogether. Running them form the commandline yields the following:
Can't find source path /tmp/.X11-unix/X1: No such file or directory
A simple restart would suffice to fix that issue, however. It happens every once in a while randomly but when it does happen, it starts from login and persists until reboot or shutdown.
I'm on Fedora 26 with Kernel 4.11.9 and the NVidia driver under X11.
The text was updated successfully, but these errors were encountered: