Bug 2176759

I have GNOME installed in the F38 installation. I prevented xdg-desktop-portal-gnome from running with systemctl mask xdg-desktop-portal-gnome --user Firefox, Thunderbird, GNOME Boxes and gnome-abrt started after 1-2 seconds after masking xdg-desktop-portal-gnome. The problem appears to involve xdg-desktop-portal-gnome being run in Plasma when it shouldn't be and then timing out. This problem doesn't seem to affect Fedora-KDE-Live-x86_64-38_Beta-1.3.iso which doesn't have xdg-desktop-portal-gnome installed.

I am having similar problems with xdg-desktop-portal in Plasma
Wayland, though not in Plasma X. In X both xdg-desktop-portal and
xdg-desktop-portal-gnome are running without problems.

In Wayland:

    [koppel@dmk-laptop-21 ~]$ systemctl --user status xdg-desktop-portal
    ● xdg-desktop-portal.service - Portal service
         Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
         Active: activating (start) since Sat 2023-03-11 16:09:08 CST; 24s ago
       Main PID: 6160 (xdg-desktop-por)
          Tasks: 4 (limit: 18156)
         Memory: 1.6M
            CPU: 23ms
         CGroup: /user.slice/user-1000.slice/user/session.slice/xdg-desktop-portal.service
                 └─6160 /usr/libexec/xdg-desktop-portal

    Mar 11 16:09:08 dmk-laptop-21 systemd[6053]: Starting xdg-desktop-portal.ser…...
    Hint: Some lines were ellipsized, use -l to show in full.
    [koppel@dmk-laptop-21 ~]$ systemctl --user restart xdg-desktop-portal

The command above hangs. Later:

    systemctl -l --user status xdg-desktop-portal
    × xdg-desktop-portal.service - Portal service
         Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
         Active: failed (Result: timeout) since Sat 2023-03-11 16:10:31 CST; 35s ago
        Process: 7717 ExecStart=/usr/libexec/xdg-desktop-portal (code=killed, signal=TERM)
       Main PID: 7717 (code=killed, signal=TERM)
            CPU: 38ms

    Mar 11 16:09:46 dmk-laptop-21 systemd[6053]: Starting xdg-desktop-portal.service - Portal service...
    Mar 11 16:10:18 dmk-laptop-21 xdg-desktop-por[7717]: Failed to create settings proxy: Error al llamar StartSereviceByName para org.freedesktop.impl.portal.desktop.gnome: Se alcanzó el tiempo de expiración
    Mar 11 16:10:31 dmk-laptop-21 systemd[6053]: xdg-desktop-portal.service: start operation timed out. Terminating.
    Mar 11 16:10:31 dmk-laptop-21 systemd[6053]: xdg-desktop-portal.service: Failed with result 'timeout'.
    Mar 11 16:10:31 dmk-laptop-21 systemd[6053]: Failed to start xdg-desktop-portal.service - Portal service.


    systemctl -l --user status xdg-desktop-portal-gnome
    × xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)
         Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal-gnome.service; static)
         Active: failed (Result: timeout) since Sat 2023-03-11 16:10:38 CST; 2min 1s ago
        Process: 7725 ExecStart=/usr/libexec/xdg-desktop-portal-gnome (code=killed, signal=TERM)
       Main PID: 7725 (code=killed, signal=TERM)
            CPU: 13ms

    Mar 11 16:09:53 dmk-laptop-21 systemd[6053]: Starting xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)...
    Mar 11 16:10:38 dmk-laptop-21 systemd[6053]: xdg-desktop-portal-gnome.service: start operation timed out. Terminating.
    Mar 11 16:10:38 dmk-laptop-21 systemd[6053]: xdg-desktop-portal-gnome.service: Failed with result 'timeout'.
    Mar 11 16:10:38 dmk-laptop-21 systemd[6053]: Failed to start xdg-desktop-portal-gnome.service - Portal service (GNOME implementation).


But in X no problem with either service:

    [koppel@dmk-laptop-21 ~]$ systemctl --user -l status xdg-desktop-portal
    ● xdg-desktop-portal.service - Portal service
         Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
         Active: active (running) since Sat 2023-03-11 16:15:13 CST; 1min 19s ago
       Main PID: 9212 (xdg-desktop-por)
          Tasks: 7 (limit: 18156)
         Memory: 2.8M
            CPU: 75ms
         CGroup: /user.slice/user-1000.slice/user/session.slice/xdg-desktop-portal.service
                 └─9212 /usr/libexec/xdg-desktop-portal

    Mar 11 16:15:11 dmk-laptop-21 systemd[8880]: Starting xdg-desktop-portal.service - Portal service...
    Mar 11 16:15:13 dmk-laptop-21 systemd[8880]: Started xdg-desktop-portal.service - Portal service.

    [koppel@dmk-laptop-21 ~]$ systemctl --user -l status xdg-desktop-portal-gnome
    ● xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)
         Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal-gnome.service; static)
         Active: active (running) since Sat 2023-03-11 16:15:12 CST; 1min 25s ago
       Main PID: 9254 (xdg-desktop-por)
          Tasks: 12 (limit: 18156)
         Memory: 24.9M
            CPU: 234ms
         CGroup: /user.slice/user-1000.slice/user/app.slice/xdg-desktop-portal-gnome.service
                 └─9254 /usr/libexec/xdg-desktop-portal-gnome

    Mar 11 16:15:12 dmk-laptop-21 systemd[8880]: Starting xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)...
    Mar 11 16:15:12 dmk-laptop-21 systemd[8880]: Started xdg-desktop-portal-gnome.service - Portal service (GNOME implementation).

*** Bug 2182191 has been marked as a duplicate of this bug. ***

I'll add here some of my comments from the duplicate bug:

In GNOME 44.0 the xdg-desktop-portal-gnome depends on mutter if the session is Wayland.
Upon starting it waits for mutter on the session dbus. If mutter never started, systemd makes xdg-desktop-portal-gnome time out.
At the same time, the generic xdg-desktop-portal.service was waiting for xdg-desktop-portal-gnome to start and it too times out and gets terminated, so no other desktop-specific portal can be used

Upstream issue: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/74

Note that the upstream issue states that the only problem is a 2min delay in portal-related actions, but that is not the case in fedora, where the xdg-desktop-portal.service gets killed after timeout so is unusable.

Proposed as a Freeze Exception for 38-final by Fedora user aleasto using the blocker tracking app because:

 Widespread issue: any user upgrading from F37 KDE to F38 KDE will be impacted.
Very visible impact: GTK applications may take up to 2 minutes to start (namely Firefox), all portal operations won't work (namely screen sharing, or anything to do with flatpaks)

I'm not convinced this is really a bug in the GNOME portal itself; it's more about why it gets run in Plasma. I'm not exactly sure whose fault that is, though. Let's CC the KDE usual suspects...

(well, hmm, I guess my comment begs a few questions; I guess we need someone who knows more about the whole portal thing in general to decide what's wrong and what needs fixing)

It is a bug in xdg-desktop-portal-gnone, it's being tracked upstream as i linked.

You can have all portals running because the system is designed to not interfere with one another. In facts, it used to be necessary to have the -gnome service running in Plasma for some functionality (i don't remember what, maybe gtk fonts). Nowdays it's not required anymore, but it was shipped by default Fedora KDE images up until F37. It's ow removed, but you will hit this issue when upgrading.

The combination of https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/78 and https://github.com/flatpak/xdg-desktop-portal/pull/985 aims to solve this.

Shall we go ahead and backport those, then? Or wait for more discussion/review?

> Shall we go ahead and backport those, then? Or wait for more discussion/review?

If not a backport immediately, scratch builds for wider testing wouldn't hurt.

GTK programs are probably more likely to result in xdg-desktop-portal-gnome being started than others, but the problem isn't specific to them and not all of them are affected by this problem. VLC which uses Qt installed in a flatpak from flathub took about 2 minutes to start due to the xdg-desktop-portal and xdg-desktop-portal-gnome timeouts happening 3 times each in Plasma in my F38 KDE Plasma installation when it normally started in a second. The SELinux Troubleshooter program sealert which uses GTK started normally in 2 seconds in the same enviroment, and no xdg-desktop-portal-gnome timeouts were shown. The problem might depend on whether the program starting results in xdg-desktop-portal-gnome being started and timing out in Plasma instead of whether they're GTK-based or otherwise. Thanks.

Scratch builds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=99381518 (xdg-desktop-portal)
https://koji.fedoraproject.org/koji/taskinfo?taskID=99381568 (xdg-desktop-portal-gnome)
Can folks try those and see how they go? Thanks!

It fixed the problem for me, which is different than the OP (see
Comment 2). In my case I'm connecting to the portal via dbus from
within Emacs under KDE/Wayland.

(dbus-call-method
            :session
            "org.freedesktop.portal.Desktop"
            "/org/freedesktop/portal/desktop"
            "org.freedesktop.portal.Settings"
            "Read"
            :timeout 100
            "org.freedesktop.appearance" "color-scheme")

With the two scratch builds xdg-desktop-portal is returning promptly
on Wayland. (There was never a problem on X.)

Firefox, Thunderbird, GNOME Boxes, gnome-abrt, and VLC had normal startup times with xdg-desktop-portal-1.16.0-2.1.awb.2176759.x86_64 and xdg-desktop-portal-gnome-44.0-1.1.awb.2176759.x86_64. There was a different xdg-desktop-portal-gnome failure when logging into Plasma which repeated.

Mar 31 20:54:12 systemd[1257]: Starting xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)...
Mar 31 20:54:12 wireplumber[1324]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NameHasNoOwner
Mar 31 20:54:12 kwin_wayland[1320]: No backend specified, automatically choosing drm
Mar 31 20:54:12 xdg-desktop-portal-gnome[1370]: Failed to initialize display server connection: Cannot invoke method; proxy is for the well-known name org.gnome.Mutter.ServiceChannel without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
Mar 31 20:54:12 systemd[1257]: xdg-desktop-portal-gnome.service: Main process exited, code=exited, status=1/FAILURE
Mar 31 20:54:12 systemd[1257]: xdg-desktop-portal-gnome.service: Failed with result 'exit-code'.
Mar 31 20:54:12 systemd[1257]: Failed to start xdg-desktop-portal-gnome.service - Portal service (GNOME implementation).

The same type of xdg-desktop-portal-gnome failure happened when starting GNOME Boxes and VLC.

Mar 31 20:54:23 plasmashell[1473]: QString::arg: 2 argument(s) missing in org.gnome.Boxes
Mar 31 20:54:23 systemd[1257]: Started dbus-:1.2-org.gnome.Boxes.
...
Mar 31 20:54:24 xdg-desktop-portal-kde[1513]: xdp-kde-settings: Namespace  "org.gnome.desktop.a11y.interface"  is not supported
Mar 31 20:54:24 systemd[1257]: Starting xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)...
Mar 31 20:54:24 xdg-desktop-portal-gnome[2255]: Failed to initialize display server connection: Cannot invoke method; proxy is for the well-known name org.gnome.Mutter.ServiceChannel without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
Mar 31 20:54:24 systemd[1257]: xdg-desktop-portal-gnome.service: Main process exited, code=exited, status=1/FAILURE
Mar 31 20:54:24 systemd[1257]: xdg-desktop-portal-gnome.service: Failed with result 'exit-code'.
Mar 31 20:54:24 systemd[1257]: Failed to start xdg-desktop-portal-gnome.service - Portal service (GNOME implementation).
...
Mar 31 20:55:08 plasmashell[1473]: QString::arg: 2 argument(s) missing in org.videolan.VLC
Mar 31 20:55:08 systemd[1257]: Started app-org.videolan.VLC-9760a316056347f4bdef53497091a09d.scope - VLC media player - Media player.
Mar 31 20:55:08 systemd[1257]: Starting flatpak-session-helper.service - flatpak session helper...
Mar 31 20:55:08 systemd[1257]: Started flatpak-session-helper.service - flatpak session helper.
Mar 31 20:55:09 systemd[1257]: Started app-flatpak-org.videolan.VLC-2370.scope.
Mar 31 20:55:09 plasmashell[2390]: [00005616911f8710] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
Mar 31 20:55:09 systemd[1257]: Starting xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)...
Mar 31 20:55:09 xdg-desktop-portal-gnome[2398]: Failed to initialize display server connection: Cannot invoke method; proxy is for the well-known name org.gnome.Mutter.ServiceChannel without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
Mar 31 20:55:09 systemd[1257]: xdg-desktop-portal-gnome.service: Main process exited, code=exited, status=1/FAILURE
Mar 31 20:55:09 systemd[1257]: xdg-desktop-portal-gnome.service: Failed with result 'exit-code'.
Mar 31 20:55:09 systemd[1257]: Failed to start xdg-desktop-portal-gnome.service - Portal service (GNOME implementation).
Mar 31 20:55:09 xdg-desktop-por[1334]: Failed to ReadAll() from Settings implementation: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer: startup job failed.
Mar 31 20:55:10 plasmashell[2390]: kf.notifications: env says KDE is running but SNI unavailable -- check KDE_FULL_SESSION and XDG_CURRENT_DESKTOP
Mar 31 20:55:10 plasmashell[2390]: [0000561691294520] main playlist: playlist is empty
Mar 31 20:55:12 kwin_wayland[1320]: This plugin does not support raise()

Those errors didn't happen when starting Firefox, Thunderbird, or gnome-abrt. Thanks.

Indeed xdg-desktop-portal-gnome now immediatly fails to start instead of waiting 2 minutes for Mutter to show up on dbus. So xdg-desktop-portal can go on with the other desktop-specific portals.

Scratch builds restore expected behavior for me

Discussed during the 2023-04-03 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2023-04-03/f38-blocker-review.2023-04-03-16.01.txt

(In reply to Adam Williamson from comment #13)

Hijacking a bit this bug report: I've installed the scratch builds and now Google Chrome works properly [1].
Though I'm still getting:

    xdg-desktop-portal-gnome[17716]: Failed to initialize display server connection: Unsupported or missing session type ''

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2183622#c4

I'm experiencing 2 to 2 1/2-minute startup times with GTK apps (installed with DNF) in Plasma.

Flatpak apps are an issue as well (BOTH GTK and Qt apps - in fact in the case of flatpak, Qt apps are the slowest).

This only cropped up several weeks ago.  It wasn't an issue in F38 prior to that time.

I've been running F38 on bare metal since a few days after it branched from Rawhide.

Does anyone know when this will be fixed?  Having to wait for 5 minutes for apps to start is kind of annoying, and apparently it's not easy to
remove without potential causing other issues:

dnf remove xdg-desktop-portal-gnome
Error: 
 Problem: The operation would result in removing the following protected packages: gnome-shell

(In reply to Gerald Cox from comment #21)
> Does anyone know when this will be fixed?  Having to wait for 5 minutes for
> apps to start is kind of annoying…

Merging of the patches upstream are still waiting on review. Please try the scratch builds in comment #13 and report back if they work for you.

(In reply to David King from comment #22)
> Merging of the patches upstream are still waiting on review. Please try the
> scratch builds in comment #13 and report back if they work for you.

$ rpm -qa | grep awb
xdg-desktop-portal-1.16.0-2.1.awb.2176759.x86_64
xdg-desktop-portal-gnome-44.0-1.1.awb.2176759.x86_64

Works for me.

By the way, this bug is not limited to GTK applications. Telegram Desktop (uses Qt) installed via flatpak takes more than 10 minutes to start.

(In reply to Ivan Mironov from comment #23)
> By the way, this bug is not limited to GTK applications. Telegram Desktop
> (uses Qt) installed via flatpak takes more than 10 minutes to start.

See comment #20.

agh, shoot. Sorry, I lost track of this and forgot to do official builds/update. This probably won't make 38 Final now, but I'll do builds and put them in updates-testing at least.

(In reply to Adam Williamson from comment #25)
> agh, shoot. Sorry, I lost track of this and forgot to do official
> builds/update. This probably won't make 38 Final now, but I'll do builds and
> put them in updates-testing at least.

Thanks Adam!

FEDORA-2023-d44b42a891 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d44b42a891

Proposed as a Blocker for 38-final by Fedora user bcotton using the blocker tracking app because:

 This is a arguably a conditional violation of the final criterion "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."

It applies in cases where a user upgrades from F36 or F37 to F38. One could oppose this on the grounds that the menu does its job. It's just that a no-longer-default package fails. Arguably, that's a meaningless distinction from the user perspective .

(In reply to Adam Williamson from comment #25)
> agh, shoot. Sorry, I lost track of this and forgot to do official
> builds/update. This probably won't make 38 Final now, but I'll do builds and
> put them in updates-testing at least.

Adam, this is already accepted FE, it can be on the next RC 1.2?

Oh, sorry, my mistake. This packages don't even get shipped at the iso.

FEDORA-2023-d44b42a891 has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d44b42a891

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

(In reply to Fedora Update System from comment #31)
> FEDORA-2023-d44b42a891 has been pushed to the Fedora 38 testing repository.

Fixes the timeout issue in my testing.

+6 blocker/0-day votes in https://pagure.io/fedora-qa/blocker-review/issue/1133 , marking Accepted0Day - as a reminder, that means this fix does not need to go on the media, but needs to be pushed stable before release day. (Note we probably *will* include it in the compose anyhow, since we're going to need an RC-1.2 compose, but for the record).

FEDORA-2023-d44b42a891 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

I think I had this exact problem, but "reversed", with plasma-xdg-desktop-portal-kde preventing apps to start "fast" on Gnome.

`systemctl --user mask plasma-xdg-desktop-portal-kde.service` resolved the issue.

Should I open a separate issue?

Thanks a lot already.

(In reply to philip from comment #35)

Yes, please. And add it to the Links section here, thanks.