New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Realtime error: Could not map pid: Could not determine pid namespace: Could not find instance-id in process's /.flatpak-info #1167
Comments
This might just be excessively verbose. And not even caused by Evolution per-see. |
I just used Evolution launch as a quick reproducer. This also occurs when starting Libreoffice, Firefox, Chrome, Thunar, etc. EDIT: Edited description thusly. |
You can use |
Mapping pids/tids is only necessary when apps are running inside another pid namespace. Apps on the host usually do not. If they put parts of themselves into one, it's their responsibility to do the mapping. Instead of having to make sure that the app is not a host app before calling this function, handle host apps trivially by not mapping anything and returning success. Closes: flatpak#1167
@tekstryder are those apps by any chance running as snap then? It's either that or we incorrectly classify something which would be really weird. |
Nope, native host apps. I'll build with swick@71bc452 patch and test... |
swick@71bc452 solved this for most of the apps I tested. Firefox, Chrome, Libreoffice, and Thunar no longer trigger the error. Thanks for the quick turnaround time here @swick ! Evolution still does trigger this... it's always been a bit special :) |
The point is, it shouldn't. The patch isn't a behavioral change. |
I'm not clear what you mean by this. I tested further, and launched every app I have installed (50-ish). No other app except Evolution causes this error to emit now after applying your change. Seems like a win to me. |
Can you test upstream main? |
Sure, I'll build from 0fb760e. Gimme a few... |
Hmm, building from main failed meson tests. Should I disable tests and build regardless? Build test failures
|
Ah, the same results as #1167 (comment) when testing main. I packaged 1.18.0+r32+g0fb760e, albeit skipping a meson build failure. Looks good. EDIT: I'm a bit flummoxed as to why this is behaving differently on main vs release 1.18.0? Nothing jumps out at me after reviewing the relatively small changeset: 1.18.0...main |
I also looked at the blame and didn't see anything suspicious. Still think we can close this. |
Okay, thanks for your prompt investigation. I'll stay on today's main build until next release. Closing. |
Reopening this, having come full-circle among involved projects. Subsequently reported against evolution here: And then off to WebKitGTK here: Alas, now directed per Webkit folks back here to where I began. Milan's (Evolution developer) comment, after his investigation, made sense to me that this would be an issue in WebKit's sandbox implementation.
However, per the response on WebKit issue:
Perhaps this condition could be handled without logging an error to the system journal, as it appears there is not a functionality issue here. Evolution's limited use of the D-Bus service succeeds, and WebKit "doesn't have a real flatpak instance". |
Yeah, so just not printing a warning when the instance ID is missing would be a start. Alternatively, we could add some key to the flatpak-info to indicate that we're not really flatpak, and xdg-desktop-portal could print the warning only if that key is missing. A more ambitious approach would be to define an entirely new file format to tell xdg-desktop-portal that we're sandboxed, so non-flatpak sandboxes don't have to create a flatpak-info file anymore. Probably not necessary, but it would certainly help avoid confusion and mistakes. |
Patrick was able to fix this in WebKit after all: WebKit/WebKit#23052 |
I built webkit2gtk-4.1 2.42.4 + WebKit/WebKit#23052, and can confirm it resolved this. Thanks everyone! Closing |
Operating System
Arch Linux
XDG Desktop Portal version
1.18
XDG Desktop Portal version (Other)
xdg-desktop-portal-gtk 1.15.1
xdg-desktop-portal-gnome 45.0
Desktop Environment
GNOME
Desktop Environment (Other)
gnome-shell --no-x11
Expected Behavior
Run without logging errors in the system journal.
Current Behavior
I can reproduce this easily by launching Evolution mail app for instance:
Steps to Reproduce
Note: those were just the apps I noticed that, when launched, triggered this error emitted by xdg-desktop-portal at a quick grep.
I'm sure there are many more.
Anything else we should know?
xdg-desktop-portal
was pulled in recently as a dependency by nautilus/libportal.I do not use flatpak.
The text was updated successfully, but these errors were encountered: