xdg-desktop-portal Will Not Run, Causing all (even non-Flatpak) dbus GTK Apps to Take Forever to Open on Plasma

[gardotd426]

Linux distribution and version

Arch Linux

Flatpak version

1.10.1

Description of the problem

Starting maybe two weeks ago, I've had to remove all flatpaks and even the flatpak package itself from my system, as it depends on xdg-desktop-portal and won't accept xdg-desktop-portal-gtk or -kde as replacements/provides. Well, it's causing non-flatpak GTK apps like virt-manager, Nautilus, and Nemo to take 30 seconds to open on a high-end machine with all-NVME storage and 32GB of RAM. QT and electron apps open instantly.

Weirdly, when I log into Budgie or i3, apps start instantly. I've traced the problem to xdg-desktop-portal. The systemd service fails to start with no error message, just saying that it timed out:

systemctl --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 2021-02-13 18:56:27 EST; 15s ago
    Process: 601276 ExecStart=/usr/lib/xdg-desktop-portal (code=killed, signal=TERM)
   Main PID: 601276 (code=killed, signal=TERM)

Feb 13 18:53:27 matt-archlinux systemd[1793]: Starting Portal service...
Feb 13 18:56:27 matt-archlinux systemd[1793]: xdg-desktop-portal.service: start operation timed out. Terminating.
Feb 13 18:56:27 matt-archlinux systemd[1793]: xdg-desktop-portal.service: Failed with result 'timeout'.
Feb 13 18:56:27 matt-archlinux systemd[1793]: Failed to start Portal service.

Running it from the terminal also doesn't work, it just hangs there and never completes.

I'm fully aware of the former fix that could be achieved by running: dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY. That does a whole lot of absolutely nothing in this case. I've tried it a dozen times (or more).

The only thing that's stopped the issue, and stopped it instantly, is removing flatpak and xdg-desktop-portal from my system.

Steps to reproduce

Be on Arch Linux running KDE Plasma.

Install flatpak and by extension xdg-desktop-portal

Reboot

Try to run nautilus, virt-manager, or nemo. They will take way longer than they have any business taking (30-45 seconds on my machine with an 8-core 16-thread Zen 3 CPU, 32GB of RAM and all high-speed flash storage).

I've gone ahead and gotten the output from /usr/lib/xdg-desktop-portal --replace --verbose:

/usr/lib/xdg-desktop-portal --replace --verbose
XDP: load portals from /usr/share/xdg-desktop-portal/portals
XDP: loading /usr/share/xdg-desktop-portal/portals/gtk.portal
XDP: portal implementation for gnome
XDP: portal implementation supports org.freedesktop.impl.portal.FileChooser
XDP: portal implementation supports org.freedesktop.impl.portal.AppChooser
XDP: portal implementation supports org.freedesktop.impl.portal.Print
XDP: portal implementation supports org.freedesktop.impl.portal.Screenshot
XDP: portal implementation supports org.freedesktop.impl.portal.Notification
XDP: portal implementation supports org.freedesktop.impl.portal.Inhibit
XDP: portal implementation supports org.freedesktop.impl.portal.Access
XDP: portal implementation supports org.freedesktop.impl.portal.Account
XDP: portal implementation supports org.freedesktop.impl.portal.Email
XDP: portal implementation supports org.freedesktop.impl.portal.ScreenCast
XDP: portal implementation supports org.freedesktop.impl.portal.RemoteDesktop
XDP: portal implementation supports org.freedesktop.impl.portal.Lockdown
XDP: portal implementation supports org.freedesktop.impl.portal.Background
XDP: portal implementation supports org.freedesktop.impl.portal.Settings
XDP: portal implementation supports org.freedesktop.impl.portal.Wallpaper
XDP: loading /usr/share/xdg-desktop-portal/portals/gnome-shell.portal
XDP: portal implementation for gnome
XDP: portal implementation supports org.freedesktop.impl.portal.Access
XDP: loading /usr/share/xdg-desktop-portal/portals/kde.portal
XDP: portal implementation for KDE
XDP: portal implementation supports org.freedesktop.impl.portal.Access
XDP: portal implementation supports org.freedesktop.impl.portal.Account
XDP: portal implementation supports org.freedesktop.impl.portal.AppChooser
XDP: portal implementation supports org.freedesktop.impl.portal.Background
XDP: portal implementation supports org.freedesktop.impl.portal.Email
XDP: portal implementation supports org.freedesktop.impl.portal.FileChooser
XDP: portal implementation supports org.freedesktop.impl.portal.Inhibit
XDP: portal implementation supports org.freedesktop.impl.portal.Notification
XDP: portal implementation supports org.freedesktop.impl.portal.Print
XDP: portal implementation supports org.freedesktop.impl.portal.ScreenCast
XDP: portal implementation supports org.freedesktop.impl.portal.Screenshot
XDP: portal implementation supports org.freedesktop.impl.portal.RemoteDesktop
XDP: portal implementation supports org.freedesktop.impl.portal.Settings
XDP: loading /usr/share/xdg-desktop-portal/portals/gnome-keyring.portal
XDP: portal implementation for gnome
XDP: portal implementation supports org.freedesktop.impl.portal.Secret
XDP: Falling back to gtk.portal for org.freedesktop.impl.portal.Lockdown
XDP: providing portal org.freedesktop.portal.MemoryMonitor
XDP: providing portal org.freedesktop.portal.NetworkMonitor
XDP: providing portal org.freedesktop.portal.ProxyResolver
XDP: providing portal org.freedesktop.portal.Trash
XDP: providing portal org.freedesktop.portal.GameMode
XDP: Using gtk.portal for org.freedesktop.impl.portal.Settings
XDP: Using kde.portal for org.freedesktop.impl.portal.Settings
XDP: providing portal org.freedesktop.portal.Settings
XDP: Using kde.portal for org.freedesktop.impl.portal.FileChooser in KDE
XDP: providing portal org.freedesktop.portal.FileChooser
XDP: Using kde.portal for org.freedesktop.impl.portal.AppChooser in KDE
XDP: providing portal org.freedesktop.portal.OpenURI
XDP: Using kde.portal for org.freedesktop.impl.portal.Print in KDE
XDP: providing portal org.freedesktop.portal.Print
XDP: Using kde.portal for org.freedesktop.impl.portal.Screenshot in KDE
XDP: providing portal org.freedesktop.portal.Screenshot
XDP: Using kde.portal for org.freedesktop.impl.portal.Notification in KDE
XDP: providing portal org.freedesktop.portal.Notification
XDP: Using kde.portal for org.freedesktop.impl.portal.Inhibit in KDE
XDP: providing portal org.freedesktop.portal.Inhibit
XDP: Using kde.portal for org.freedesktop.impl.portal.Access in KDE
XDP: Using kde.portal for org.freedesktop.impl.portal.Background in KDE
XDP: providing portal org.freedesktop.portal.Device
XDP: providing portal org.freedesktop.portal.Location

And it's just hanging there, and apps are still taking forever to open.

[kokoko3k]

This is exactly what i'm facing.
https://bbs.archlinux.org/viewtopic.php?pid=1964330#p1964330

[kokoko3k]

just rebooted, issued the following:
while true ; do timeout 1 /usr/lib/xdg-desktop-portal -r -v ; sleep 1 ; done
after a couple of seconds it completed the bootstrap, and after that it worked for any subsequent runs.
What is going on?

see here:
https://bbs.archlinux.org/viewtopic.php?id=262897

[gardotd426]

Same here. I just did the same, ran the while true command, a couple seconds later I launched some apps that I know stall when it's not working properly, they launched instantly, I ended the command, waited a couple seconds, tried launching the apps again, they still launched instantly, so I checked systemctl --user status xdg-desktop-portal.service and it succeeded (albeit with a couple errors).

[smcv]

This looks like an xdg-desktop-portal bug rather than a flatpak bug.

[gardotd426]

xdg-desktop-portal is software developed by flatpak. Though I guess this could be moved to the xdg-desktop-portal repository, if anyone that has privileges here wants to move it. Obviously I can't move it myself. But yeah, if someone moves it to https://github.com/flatpak/xdg-desktop-portal/issues, that'd be fine.

[anarsoul]

I believe the issue is stale /etc/pipewire/pipewire.conf. Basically it's the config from previous version of package, newer config is saved as /etc/pipewire/pipewire.conf.pacnew. Just do sudo mv /etc/pipewire/pipewire.conf.pacnew /etc/pipewire/pipewire.conf and it should fix the issue.

[kokoko3k]

This could be the issue indeed, seems to work right now.
Will update if i'll face the issue again.

[gardotd426]

Yeah weirdly enough I found this out by accident as well. Like two weeks ago I switched from PulseAudio to Pipewire but that required me replacing the config file with the .pacnew one. After that I hadn't had any issues, but my GPU died like two days later, and I'm currently awaiting the arrival of my RMA replacement from EVGA, so I haven't had access to my desktop (which is where I was encountering the issue). But I got the emails from this thread and figured I'd pop in to say that yeah I think that was the issue. I'll go ahead and close.

[gilgamesh3]

So I think that the problem isn't solved yet. Recently the pipewire package on Arch Linux changed and the "factory config files were moved from /etc/pipewire to /usr/share/pipewire"[1], even then if I try to put pipewire.conf in /etc/pipewire/ or $XDG_CONFIG_HOME/pipewire/ (I'm running pipewire as a user service), xdg-desktop-portal will still fail to start and then my telegram-desktop (it isn't running as a flatpak package) will take up to 1 minute to start and probably others packages too. So as far as I can see the only thing I can do is:

1. Run "dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY" everytime i3wm launches;

Or

2. Uninstall flatpak and xdg-desktop-portals.

For me, I uninstalled flatpak and its dependencies from my OS and I probably won't use it again until I can find a reasonable solution for this problem.

Then after all that I think the issue should be reopened.

[gardotd426]

I can't reproduce on plasma. I'm not using i3 right now (but I do have it installed), I'm using plasma, but even though my config files were also moved to /usr/share/pipewire, xdg-desktop-portal starts fine and GTK apps open immediately. I even restarted the systemd services for both pipewire and xdg-desktop-portal and still couldn't reproduce.

[resolritter]

I finally debugged why it was not starting. For me it was also stuck in that line:

XDP: providing portal org.freedesktop.portal.Location

I noticed the pipewire service did start but it warned it wasn't loading any modules. It would say something like:

pipewire[17887]: no modules loaded from context.modules

So in a nutshell this seems to be the problem: I needed to load the portal module, however the pipewire.conf's format had changed between versions and I still had the outdated format, therefore the configuration was not being parsed correctly, thus the portal module was not being loaded.

flatpak/xdg-desktop-portal-gtk#107 (comment) did not work for me because the .pacnew file still was using the old format. I can tell by the first line:

#daemon config file for PipeWire version "0.3.10"

Solution

My version is 0.3.30 which needs the new format (reference). In my Arch installation (flatpak package) it's running as a user service so I created a file in ~/.config/pipewire/pipewire.conf.

pipewire.conf

context.properties = {
    ## Configure properties in the system.
    #library.name.system                   = support/libspa-support
    #context.data-loop.library.name.system = support/libspa-support
    support.dbus                          = true
    #link.max-buffers                      = 64
    link.max-buffers                       = 16                       # version < 3 clients can't handle more
    #mem.warn-mlock                        = false
    #mem.allow-mlock                       = true
    #mem.mlock-all                         = false
    #clock.power-of-two-quantum            = true
    log.level                             = 2

    core.daemon                            = true                     # listening for socket connections
    core.name                              = pipewire-0               # core name and socket name

    ## Properties for the DSP configuration.
    default.clock.rate        = 48000
    default.clock.quantum     = 1024
    #default.clock.min-quantum = 32
    #default.clock.max-quantum = 8192
    #default.video.width       = 640
    #default.video.height      = 480
    #default.video.rate.num    = 25
    #default.video.rate.denom  = 1
    #
    # These overrides are only applied when running in a vm.
    vm.overrides = {
        default.clock.min-quantum     = 1024
    }
}

context.spa-libs = {
    #<factory-name regex> = <library-name>
    #
    # Used to find spa factory names. It maps an spa factory name
    # regular expression to a library name that should contain
    # that factory.
    #
    audio.convert.* = audioconvert/libspa-audioconvert
    api.alsa.*      = alsa/libspa-alsa
    api.v4l2.*      = v4l2/libspa-v4l2
    api.libcamera.* = libcamera/libspa-libcamera
    api.bluez5.*    = bluez5/libspa-bluez5
    api.vulkan.*    = vulkan/libspa-vulkan
    api.jack.*      = jack/libspa-jack
    support.*       = support/libspa-support
    PIPEWIRE_LATENCY=256/48000 jack_simple_client
#videotestsrc   = videotestsrc/libspa-videotestsrc
    #audiotestsrc   = audiotestsrc/libspa-audiotestsrc
}

context.modules = [
    #{   name = <module-name>
    #    [ args = { <key> = <value> ... } ]
    #    [ flags = [ [ ifexists ] [ nofail ] ]
    #}
    #
    # Loads a module with the given parameters.
    # If ifexists is given, the module is ignored when it is not found.
    # If nofail is given, module initialization failures are ignored.
    #

    # Uses RTKit to boost the data thread priority.
    {   name = libpipewire-module-rtkit
        args = {
            #nice.level   = -11
            #rt.prio      = 88
            #rt.time.soft = 200000
            #rt.time.hard = 200000
        }
        flags = [ ifexists nofail ]
    }

    # The native communication protocol.
    {   name = libpipewire-module-protocol-native }

    # The profile module. Allows application to access profiler
    # and performance data. It provides an interface that is used
    # by pw-top and pw-profiler.
    {   name = libpipewire-module-profiler }

    # Allows applications to create metadata objects. It creates
    # a factory for Metadata objects.
    {   name = libpipewire-module-metadata }

    # Creates a factory for making devices that run in the
    # context of the PipeWire server.
    {   name = libpipewire-module-spa-device-factory }

    # Creates a factory for making nodes that run in the
    # context of the PipeWire server.
    {   name = libpipewire-module-spa-node-factory }

    # Allows creating nodes that run in the context of the
    # client. Is used by all clients that want to provide
    # data to PipeWire.
    {   name = libpipewire-module-client-node }

    # Allows creating devices that run in the context of the
    # client. Is used by the session manager.
    {   name = libpipewire-module-client-device }

    # The portal module monitors the PID of the portal process
    # and tags connections with the same PID as portal
    # connections.
    {   name = libpipewire-module-portal
        flags = [ ifexists nofail ]
    }

    # The access module can perform access checks and block
    # new clients.
    {   name = libpipewire-module-access
        args = {
            # access.allowed to list an array of paths of allowed
            # apps.
            #access.allowed = [
            #    /usr/bin/pipewire-media-session
            #]

            # An array of rejected paths.
            #access.rejected = [ ]

            # An array of paths with restricted access.
            #access.restricted = [ ]

            # Anything not in the above lists gets assigned the
            # access.force permission.
            #access.force = flatpak
        }
    }

    # Makes a factory for wrapping nodes in an adapter with a
    # converter and resampler.
    {   name = libpipewire-module-adapter }

    # Makes a factory for creating links between ports.
    {   name = libpipewire-module-link-factory }

    # Provides factories to make session manager objects.
    {   name = libpipewire-module-session-manager }
]

context.objects = [
    #{   factory = <factory-name>
    #    [ args  = { <key> = <value> ... } ]
    #    [ flags = [ [ nofail ] ]
    #}
    #
    # Creates an object from a PipeWire factory with the given parameters.
    # If nofail is given, errors are ignored (and no object is created).
    #
    #{ factory = spa-node-factory args = { factory.name = videotestsrc node.name = videotestsrc Spa:Pod:Object:Param:Props:patternType = 1 } }
    #{ factory = spa-device-factory args = { factory.name = api.jack.device foo=bar } flags = [ nofail ] }
    #{ factory = spa-device-factory args = { factory.name = api.alsa.enum.udev } }
    #{ factory = spa-device-factory args = { factory.name = api.alsa.seq.bridge node.name = Internal-MIDI-Bridge } }
    #{ factory = adapter            args = { factory.name = audiotestsrc node.name = my-test } }
    #{ factory = spa-node-factory   args = { factory.name = api.vulkan.compute.source node.name = my-compute-source } }

    # A default dummy driver. This handles nodes marked with the "node.always-driver"
    # property when no other driver is currently active. JACK clients need this.
    {   factory = spa-node-factory
        args = {
            factory.name    = support.node.driver
            node.name       = Dummy-Driver
            node.group      = pipewire.dummy
            priority.driver = 20000
        }
    }
    # This creates a new Source node. It will have input ports
    # that you can link, to provide audio for this source.
    #{   factory = adapter
    #    args = {
    #        factory.name     = support.null-audio-sink
    #        node.name        = "my-mic"
    #        node.description = "Microphone"
    #        media.class      = "Audio/Source/Virtual"
    #        audio.position   = "FL,FR"
    #    }
    #}

    # This creates a single PCM source device for the given
    # alsa device path hw:0. You can change source to sink
    # to make a sink in the same way.
    #{   factory = adapter
        #args = {
            #factory.name            = api.alsa.pcm.source
            #node.name               = "alsa-source"
            #node.description        = "PCM Source"
            #media.class             = "Audio/Source"
            #api.alsa.path           = "hw:0"
            #api.alsa.period-size   = 1024
            #api.alsa.headroom      = 0
            #api.alsa.disable-mmap  = false
            #api.alsa.disable-batch = false
            #audio.format           = "S16LE"
            #audio.rate             = 48000
            #audio.channels         = 2
            #audio.position         = "FL,FR"
        #}
    #}
]

context.exec = [
    #{ path = <program-name> [ args = "<arguments>" ] }
    #
    # Execute the given program with arguments.
    #
    # You can optionally start the session manager here,
    # but it is better to start it as a systemd service.
    # Run the session manager with -h for options.
    #
    { path = "/usr/bin/pipewire-media-session"  args = "" }
    #
    # You can optionally start the pulseaudio-server here as well
    # but it is better to start it as a systemd service.
    # It can be interesting to start another daemon here that listens
    # on another address with the -a option (eg. -a tcp:4713).
    #
    #{ path = "/usr/bin/pipewire" args = "-c pipewire-pulse.conf" }
]

For Arch you'll also have to install pipewire-media-session which is not included in the flatpak package (a bug, probably).

EDIT: In any case I still need to run dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY apparently

[ivilata]

[…] xdg-desktop-portal will still fail to start and then my telegram-desktop (it isn't running as a flatpak package) will take up to 1 minute to start and probably others packages too. So as far as I can see the only thing I can do is:

1. Run "`dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY`" everytime i3wm launches;

Or

1. Uninstall `flatpak` and `xdg-desktop-portals`.

For me, I uninstalled flatpak and its dependencies from my OS and I probably won't use it again until I can find a reasonable solution for this problem. […]

Just for the record, I faced a similar situation with Debian Sid (running environment from ~/.xsession though I'm unsure if that matters) and dbus-update-activation-environment didn't help. I ended up purging xdg-desktop-portal which pulled xdg-desktop-portal-gtk and PipeWire with it. And lo and behold, the problem was gone.

[vchernin]

I ended up having this problem or something very similar. I could not launch any Flatpak apps using the GNOME runtime (although strangely the FreeDesktop runtime seemed fine, but that needs confirmation). Note there was no 30 second delay, a few hours passed and those Flatpaks did not open.

I was debugging a unrelated issue where I was entering flatpak permission-reset app-name many times. I was also frequently using the force quit and allow button from this dialog (shown when an app tries to run in the background for the first time).

If it it's helpful I can try to make exact reproducer steps, admittely this might be hard since this seems to need repeating something an unknown amount of times...

It seems the source/cause was lots of requests/D-bus calls to xdg-desktop-portal. I tried to restart a few processes, but the one that actually fixed the issue was killing xdg-desktop-portal. Upon killing it all the apps I'd be trying to open opened.

Note the app in particular was a PipeWire native app: EasyEffects. I have no real idea of whether PipeWire/WirePlumber was involved or at fault.

[mrsudarshanrai]

So I think that the problem isn't solved yet. Recently the pipewire package on Arch Linux changed and the "factory config files were moved from /etc/pipewire to /usr/share/pipewire"[1], even then if I try to put pipewire.conf in /etc/pipewire/ or $XDG_CONFIG_HOME/pipewire/ (I'm running pipewire as a user service), xdg-desktop-portal will still fail to start and then my telegram-desktop (it isn't running as a flatpak package) will take up to 1 minute to start and probably others packages too. So as far as I can see the only thing I can do is:

1. Run "dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY" everytime i3wm launches;

Or

2. Uninstall flatpak and xdg-desktop-portals.

For me, I uninstalled flatpak and its dependencies from my OS and I probably won't use it again until I can find a reasonable solution for this problem.

Then after all that I think the issue should be reopened.

Since last week, I've been experiencing recurring issues with my Arch i3 WM setup. I've noticed a significant delay when launching my nemo file manager, which is taking longer than usual.

To troubleshoot the problem, I attempted to open the thunar file manager as an alternative, but encountered the same delay, with the launch time averaging around 15 to 20 seconds. Surprisingly, other applications such as Chrome, Firefox, and Vscode open without any problems.

Additionally, I discovered that even a file manager app I was developing using tauri/nextJs was affected, exhibiting the same delayed launch time.

After removing xdg-desktop-portal, the problem seems to have been resolved, at least for now.

[smcv]

If you are still seeing symptoms similar to this, instead of replying to a closed issue reported by someone else, please open a new issue with details of your system, and what appears in the system log (for example systemd Journal or ~/.xsession-errors) during the period of time from trying to start your app to your app starting successfully.

Something like "it takes a long time" is not enough information to isolate a root cause or fix a bug, and it is entirely possible that the root cause for slowness on your system is not the same as the root cause for slowness on other systems, so information provided by others is not necessarily going to help to isolate why this is happening for you. If we mix up more than one root cause on the same issue report, it becomes confusing and time-consuming to solve.

The output from running /usr/lib/xdg-desktop-portal --replace --verbose (or whatever location your operating system uses, it might also be /usr/libexec/xdg-desktop-portal or similar) is also likely to be helpful information.