jurf
commented
4 years ago Should mention that there is no CPU nor disk activity during the wait. The Fedora installation is, apart from some minor changes, completely standard.
Closed jurf closed 4 years ago
jurf
commented
4 years ago Should mention that there is no CPU nor disk activity during the wait. The Fedora installation is, apart from some minor changes, completely standard.
jurf
commented
4 years ago Well, turns out removing xdg-desktop-portal fixes the issue, but that’s not really a solution.
refi64
commented
4 years ago Could it be a timeout trying to talk to the portal for something? Is there anything in the journal around the time this occurs?
On Fri, Nov 15, 2019, 11:28 AM Juraj Fiala notifications@github.com wrote:
Well, turns out removing xdg-desktop-portal-gtk fixes the issue, but that’s not really a solution.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/flatpak/flatpak/issues/3223?email_source=notifications&email_token=AAM4YSM5VTKR2FUPWS5FIPLQT3LZ7A5CNFSM4JL2T5WKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEGEMRY#issuecomment-554452551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM4YSKWYKBD3WAY3I6ETBDQT3LZ7ANCNFSM4JL2T5WA .
jurf
commented
4 years ago Hm.
lis 15 21:39:25 argentum polkitd[934]: Registered Authentication Agent for unix-process:7811:1401105 (system bus name :1.1015 [flatpak run org.telegram.desktop], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale cs_CZ.UTF-8)
lis 15 21:39:25 argentum systemd[2405]: Starting flatpak document portal service...
lis 15 21:39:25 argentum xdg-document-portal[7818]: error: Failed to load db: invalid gvdb header
lis 15 21:39:25 argentum systemd[2405]: xdg-document-portal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
lis 15 21:39:25 argentum systemd[2405]: xdg-document-portal.service: Failed with result 'exit-code'.
lis 15 21:39:25 argentum systemd[2405]: Failed to start flatpak document portal service.
lis 15 21:39:39 argentum xdg-desktop-por[3319]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: App introspection not allowedThe xdg-document-portal[7818]: error: Failed to load db: invalid gvdb header looks promising.
jurf
commented
4 years ago A quick search makes it look like there’s a corrupted dconf database somewhere?
jurf
commented
4 years ago Yep, ~/.local/share/flatpak/db/documents caused the issue. Should I close this or is the corruption worth investigating?
jurf
commented
4 years ago …the file was empty? Does that make any sense?
refi64
commented
4 years ago What if you try straight up deleting the file?
On Fri, Nov 15, 2019, 3:19 PM Juraj Fiala notifications@github.com wrote:
…the file was empty? Does that make any sense?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/flatpak/flatpak/issues/3223?email_source=notifications&email_token=AAM4YSND3LKWES5CFXKM5YLQT4G67A5CNFSM4JL2T5WKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEGX5KI#issuecomment-554532521, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM4YSPMUEXXKYQCSUI6UT3QT4G67ANCNFSM4JL2T5WA .
jurf
commented
4 years ago I moved the entire folder away, no issue since then. Also, I guess the empty file makes sense – the error was because it couldn’t find the header, which definitely wasn’t in the empty file. The question is why it got there however.
refi64
commented
4 years ago The document portal writes the permission database in an atomic fashion, so afaik the only real way this would break would be either a filesystem issue or a bizarre gvdb issue. Either way, it's arguably a random fluke that at minimum would be quite hard to reproduce.
On Sat, Nov 16, 2019, 1:36 AM Juraj Fiala notifications@github.com wrote:
I moved the entire folder away, no issue since then. Also, I guess the empty file makes sense – the error was because it couldn’t find the header, which definitely wasn’t in the empty file. The question is why it got there however.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/flatpak/flatpak/issues/3223?email_source=notifications&email_token=AAM4YSIIJ26LKHWFTEJQ56DQT6PI5A5CNFSM4JL2T5WKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHLWII#issuecomment-554613537, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM4YSPL5QJSQL2XR46USPLQT6PI5ANCNFSM4JL2T5WA .
matthiasclasen
commented
4 years ago I agree that it will be hard to reproduce the issue. What we could do is to at least add the filename to the error message.
kousu
commented
3 years ago Hi there, I ran into this this week. Every GTK app I launched this week would take a long time to start. I thought it was just my cranky computer until I tried journalctl -f:
Feb 05 11:04:40 requiem systemd[694]: xdg-desktop-portal.service: start operation timed out. Terminating.
Feb 05 11:04:40 requiem systemd[694]: xdg-desktop-portal.service: Failed with result 'timeout'.
Feb 05 11:04:40 requiem systemd[694]: Failed to start Portal service.
Feb 05 11:05:10 requiem dbus-daemon[714]: [session uid=1001 pid=714] Failed to activate service 'org.freedesktop.portal.Desktop': timed out (service_start_timeout=120000ms)I googled my way to this repo and was able to guess that this would (and did) fix it for me:
$ sudo pacman -Rcns xdg-desktop-portal
checking dependencies...
:: gnome-software optionally requires flatpak: Flatpak support plugin
:: gnome-software optionally requires malcontent: Parental control plugin
Packages (5) flatpak-1.10.1-1 malcontent-0.9.0-1 ostree-2020.8-1 xdg-desktop-portal-gtk-1.8.0-1 xdg-desktop-portal-1.8.0-1
Total Removed Size: 15.71 MiB
:: Do you want to remove these packages? [Y/n]
:: Processing package changes...
(1/5) removing malcontent [######################################################################] 100%
(2/5) removing flatpak [######################################################################] 100%
(3/5) removing ostree [######################################################################] 100%
(4/5) removing xdg-desktop-portal [######################################################################] 100%
(5/5) removing xdg-desktop-portal-gtk [######################################################################] 100%
:: Running post-transaction hooks...
(1/5) Reloading system manager configuration...
(2/5) Arming ConditionNeedsUpdate...
(3/5) Reloading system bus configuration...
(4/5) Updating icon theme caches...
(5/5) Updating the desktop file MIME type cache...I can reproduce it simply by:
$ sudo pacman -S xdg-desktop-portal
resolving dependencies...
:: There are 3 providers available for xdg-desktop-portal-impl:
:: Repository extra
1) xdg-desktop-portal-gtk 2) xdg-desktop-portal-kde
:: Repository community
3) xdg-desktop-portal-wlr
Enter a number (default=1):
looking for conflicting packages...
Packages (2) xdg-desktop-portal-gtk-1.8.0-1 xdg-desktop-portal-1.8.0-1
Total Installed Size: 2.75 MiB
:: Proceed with installation? [Y/n]
(2/2) checking keys in keyring [######################################################################] 100%
(2/2) checking package integrity [######################################################################] 100%
(2/2) loading package files [######################################################################] 100%
(2/2) checking for file conflicts [######################################################################] 100%
(2/2) checking available disk space [######################################################################] 100%
:: Processing package changes...
(1/2) installing xdg-desktop-portal-gtk [######################################################################] 100%
Optional dependencies for xdg-desktop-portal-gtk
evince: Print preview [installed]
(2/2) installing xdg-desktop-portal [######################################################################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Updating the desktop file MIME type cache...and then running
$ evinceor
$ pavucontrolor
$ calibrethunar was also slow, but after uninstalling and reinstalling xdk-desktop-portal it isn't anymore; maybe it was an unrelated problem, or maybe reinstalling cleaned up something that fixed thunar in a way that didn't fix the others.
I timed it a few times and found that it's pretty consistently exactly 25 seconds from when I run evince or pavucontrol to the window showing up. For calibre it was 15 seconds, from two trials.
The journalctl logs don't seem to quite agree though, e.g. they report a timeout about two minutes after evince has appeared:
Feb 05 12:28:46 requiem dbus-daemon[714]: [session uid=1001 pid=714] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.87' (uid=1001 pid=12546 comm="evince ")
Feb 05 12:28:46 requiem systemd[694]: Starting Portal service...
## at *this* point the evince window appears
Feb 05 12:30:16 requiem systemd[694]: xdg-desktop-portal.service: start operation timed out. Terminating.
Feb 05 12:30:16 requiem systemd[694]: xdg-desktop-portal.service: Failed with result 'timeout'.
Feb 05 12:30:16 requiem systemd[694]: Failed to start Portal service.
Feb 05 12:30:46 requiem dbus-daemon[714]: [session uid=1001 pid=714] Failed to activate service 'org.freedesktop.portal.Desktop': timed out (service_start_timeout=120000ms)Maybe it's because I don't have pipewire installed?
Feb 05 12:36:23 requiem xdg-desktop-por[13515]: Failed connect to PipeWire: Couldn't connect to PipeWireBut I've only seen that message once now, but since it happened all these apps start immediately. 🤔
EDIT: Of course I do have pipewire since it's a dep, but it's not activated?
$ pacman -Qi pipewire
Name : pipewire
Version : 1:0.3.21-1
Description : Server and user space API to deal with multimedia pipelines
Architecture : x86_64
URL : https://pipewire.org
Licenses : LGPL
Groups : None
Provides : libpipewire-0.3.so=0-64
Depends On : sbc rtkit vulkan-icd-loader bluez-libs alsa-card-profiles libdbus-1.so=3-64 libncursesw.so=6-64 libsndfile.so=1-64 libudev.so=1-64 libasound.so=2-64
libsystemd.so=0-64 libldacBT_enc.so=2-64 libopenaptx.so=0-64 libfdk-aac.so=2-64
Optional Deps : pipewire-docs: Documentation
pipewire-jack: JACK support
pipewire-pulse: PulseAudio support
Required By : gnome-remote-desktop gst-plugin-pipewire mutter xdg-desktop-portal
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 5.80 MiB
Packager : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date : Wed 03 Feb 2021 07:40:50 PM
Install Date : Thu 04 Feb 2021 06:49:57 PM
Install Reason : Installed as a dependency for another package
Install Script : Yes
Validated By : Signature
$ sudo systemctl disable pipewire
Failed to disable unit: Unit file pipewire.service does not exist.
$ sudo systemctl enable pipewire
Failed to enable unit: Unit file pipewire.service does not exist.despite
$ cat /usr/lib/systemd/user/pipewire.service
[Unit]
Description=Multimedia Service
# We require pipewire.socket to be active before starting the daemon, because
# while it is possible to use the service without the socket, it is not clear
# why it would be desirable.
#
# A user installing pipewire and doing `systemctl --user start pipewire`
# will not get the socket started, which might be confusing and problematic if
# the server is to be restarted later on, as the client autospawn feature
# might kick in. Also, a start of the socket unit will fail, adding to the
# confusion.
#
# After=pipewire.socket is not needed, as it is already implicit in the
# socket-service relationship, see systemd.socket(5).
Requires=pipewire.socket
[Service]
Type=simple
ExecStart=/usr/bin/pipewire
Restart=on-failure
LimitMEMLOCK=131072
[Install]
Also=pipewire.socket
WantedBy=default.targetIt's surprising to me that Flatpak, a container system, trying to componentize and isolate pieces of our systems, accidentally reached out and affected non-Flatpak apps.
kousu
commented
3 years ago Oh and I don't have
$ ls ~/.local/share/flatpak/db/documents
ls: cannot access '/home/kousu/.local/share/flatpak/db/documents': No such file or directoryat all, so I have a different trigger for the same problem.
Linux distribution and version
F30–F31.
Flatpak version
1.4.3
Description of the problem
When launching any app, Flatpak waits for 30 seconds after
F: Add locks in dir…. After the wait it proceeds normally.