5

Ever since I updated debian, evince has been slow to startup - it takes about half a minute. Once it is open, it works fine, its just slow to open. It never used to take that long - it just used to take a couple of seconds. How can I get it going fast again?

$ uname -a
Linux mypc 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux

I noticed that evince is hanging at the following line for about half a minute:

$ strace evince
...
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 11                                    
write(11, "\1\0\0\0\0\0\0\0", 8)        = 8                                     
write(10, "\1\0\0\0\0\0\0\0", 8)        = 8                                     
futex(0x562f5b8ffac0, FUTEX_WAKE_PRIVATE, 1) = 1                                
futex(0x562f5b909b30, FUTEX_WAKE_PRIVATE, 1) = 1                                
futex(0x562f5b8bd158, FUTEX_WAKE_PRIVATE, 1) = 1                                
poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])        
read(11, "\1\0\0\0\0\0\0\0", 16)        = 8                                     
poll([{fd=11, events=POLLIN}], 1, 25000) = 0 (Timeout) # <- hanging here for a while

Then it proceeds on to open evince as normal and evince then works fine.

I have my own .xinitrc, which I'm not sure if I have configured correctly - so that could be the problem:

$ cat ~/.xinitrc 
#!/bin/bash

# update the xterm colors, font size, etc
[[ -f ~/.Xresources ]] && xrdb -merge ~/.Xresources

# run the window manager in the background first
metacity &

# get the window manager process id
wm_pid=$!

# make the window manager process id available to kill later if required
export wm_pid

# run urxvt instead of xterm since this seems able to render greek symbols etc
urxvt &

# do not let the window manager become a zombie
wait $wm_pid

Then startx is called from .bashrc. The relevant part is:

$ tail -20 ~/.bashrc

# go straight to x on login. only do this for tty1 so that we can still use the
# other tty consoles without starting x. also only do this when there is no
# display, otherwise the terminal will try and do this after x starts aswell.
# finally, only do it when x is installed (command -v startx checks if startx
# exists).
# note: as of xorg-server 1.16, x is rootless but can only be started on the
# current vt (1)
[[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && \
command -v startx > /dev/null 2>&1 && \
startx -- :0 vt1

# if using rxvt or urxvt immediately set the window to fullscreen
if [[ $TERM == *"rxvt"* ]]; then
    # make the window with rxvt in the name the active window
    wmctrl -a rxvt

    # make the active window fullscreen
    wmctrl -r ":ACTIVE:" -b add,fullscreen
fi

Edit: add some dbus information

$ ls -l ~/.dbus/session-bus/
total 28
-rw-r--r-- 1 me me 465 Nov  8 06:23 c984eb16cbd294a01d56c2ac523f7100-0
-rw-r--r-- 1 me me 465 Nov  6 14:11 c984eb16cbd294a01d56c2ac523f7100-1
-rw-r--r-- 1 me me 476 Apr 24  2017 c984eb16cbd294a01d56c2ac523f7100-10
-rw-r--r-- 1 me me 465 Jun  5  2017 c984eb16cbd294a01d56c2ac523f7100-100
-rw-r--r-- 1 me me 476 Apr  7  2017 c984eb16cbd294a01d56c2ac523f7100-11
-rw-r--r-- 1 me me 465 Nov  6 14:37 c984eb16cbd294a01d56c2ac523f7100-2
-rw-r--r-- 1 me me 463 May  6  2016 c984eb16cbd294a01d56c2ac523f7100-3
$ echo $DBUS_SESSION_BUS_ADDRESS
# empty!
mulllhausen
  • 2,648
  • 9
  • 36
  • 42
  • 1
    Go up in the trace, to know what fd=11 (or the fd the slow `poll()` is using at that time) corresponds to. That might help. You can add it to the question, right before the other snippet. – Eduardo Trápani Nov 06 '21 at 15:13
  • @EduardoTrápani I have added a few more `strace` lines from above where it hangs. I wasn't sure what I was looking for, but if you can tell me what to search for I can post it. cheers! – mulllhausen Nov 07 '21 at 13:18
  • This could help: https://bbs.archlinux.org/viewtopic.php?id=224787 – Eduardo Trápani Nov 07 '21 at 15:44
  • Looks like the D-Bus 25 second timeout: evince is trying to listen on the D-Bus session but failing. Maybe `$DBUS_SESSION_BUS_ADDRESS` is set incorrectly, or maybe there's a stale file in `~/.dbus/session-bus`. – Gilles 'SO- stop being evil' Nov 07 '21 at 19:26
  • @Gilles'SO-stopbeingevil' I have added some `dbus` information to the question. I'm guessing there should only be 1 file under `~/.dbus/session-bus`? – mulllhausen Nov 07 '21 at 20:17
  • @EduardoTrápani from that forum it looks like the solution is to add `dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY` to `~/.xinitrc`. but since `$DBUS_SESSION_BUS_ADDRESS` is blank for me, i'm guessing this will not work? – mulllhausen Nov 07 '21 at 20:27
  • it did work tho :) i guess adding `dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY` to `~/.xinitrc` is the solution – mulllhausen Nov 08 '21 at 12:57
  • I have the same issue when connecting via SSH (at least): `strace` shows a 15-second timeout followed by a 10-second timeout, thus a 25-second delay. Running `dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY` on the remote machine first solves the issue. – vinc17 Sep 01 '22 at 08:50
  • Actually it worked once. But I've tried again several times after killing all the processes, and it does not always work. Worse, the `dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY` command can even hang. – vinc17 Sep 01 '22 at 09:52

0 Answers0