You are not logged in.
Hey
Since quite some time I'm annoyed by a really slow startup of the few GNOME applications I'm using (nemo and eog).
I'm using i3 (no fancy login manager, simply started by startx from tty) and starting either of nemo or eog takes ~25s to start. Using strace I found that they are polling something with a timeout of 25000 , some more research let me to believe that they are waiting for some DBUS service (when starting them as another user I get an error that they couldn't connect to dbus and then they show up immediately and I read that dbus calls have a default timeout of 25s)
Here is a short snippet of the strace:
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 12
futex(0xd23220, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7f95a400e078, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=12, events=POLLIN}], 1, 25000) = 0 (Timeout)
you can clearly see the timeout, if you need the whole trace, let me know.
As I'm not running the whole GNOME Desktop it could very well be that I'm missing a part of GNOME that the apps assume exists. But I don't really know how I can find those.
Any ideas? What other info do you need? I'm not really understanding how to use dbus-monitor, is there a way of finding dbus calls that timeout? And see which service they're trying to reach?
Thanks in advance for your help
Solution: https://bbs.archlinux.org/viewtopic.php … 5#p1737005
Last edited by _dave18 (2017-09-19 19:39:10)
Offline
Welcome to the forums _dave18
Is your hostname set correctly?
What's the output of...
hostnamectl
Last edited by Slithery (2017-09-17 14:17:25)
Offline
Thanks for trying to help
I believe it is, output of hostnamectl:
Static hostname: arch64
Icon name: computer-laptop
Chassis: laptop
Machine ID: fd51db08294f43ab80570d42a09366bc
Boot ID: 92efe02158fd408b9845b55ac0cded53
Operating System: Arch Linux
Kernel: Linux 4.13.2-1-ARCH
Architecture: x86-64
Offline
If you suspect failing dbus calls: "man dbus-monitor"
Offline
Yeah, well, thanks, but the man page of dbus-monitor isn't exactly useful if you want to learn how to read and interpret it's output.
I simply don't see how I can find a failed/timed out call via dbus-monitor and Google didn't really help me there either. Furthermore, it doesn't even have to be a failed dbus call that is causing all this, that was just an idea, that, in my opinion, would so far fit the symptoms.
Offline
Alright, after some more digging, I kinda solved the thing.
The problematic DBUS Service was xdg-desktop-portal (org.freedesktop.impl.portal.desktop.gtk). Starting it via systemctl --user start xdg-desktop-portal-gtk failed because it couldn't connect to the display. Adding a
Environment=DISPLAY=:0
to its service file solved the problem. Now, this shouldn't be necessary at all, I'd call that a bug, the question is, which fault is it? Is systemd somehow playing up? Is the xdg-desktop-portal-gtk package at fault because it didn't add this line? Adding this to the package wouldn't work with X Displays other than :0 obviously, so this can't really be the solution.
Any ideas?
UPDATE:
I think I finally solved it the right way. Turns out you have to launch i3 via
dbus-launch --exit-with-session i3
in your .xinitrc to make sure the environment variables for dbus services are set correctly. So, back to the stock service file, replacing the line in my xinitrc starting i3 with the one mentioned solved all my problems.
Last edited by _dave18 (2017-09-19 19:56:55)
Offline
Offline
The real correct way instead of launching i3 with a dbus-launch would be to make your .xinitrc parse the necessary scripts https://wiki.archlinux.org/index.php/Xinit#xinitrc
Offline