PDF readers stops doing automatic refresh on file change

Discussions in English on using Fedora
, ,
#1

Since I updated to fedora 32 I have had the problem that after a while PDF-readers will not update on file change anymore. Rebooting will make it work for a while but it always breaks again.

My use case is that I have .tex files that I edit, and I run latexmk -pvc <file> to continuously monitor and compile changes. This part work and every time I save a change to the .tex file it runs and updates the other files. I can also manually open a new window with the pdf and then I can see the changes, but they do not show in the original window.

I have tried multiple different readers (Zathura, Atril, Okular) and all seem to have the same problem (all behave as I would want for a while after rebooting).

I assumed this was more of a fedora problem given it is over multiple different readers and it happened after the fedora 32 update. But if I’m in the wrong forum please tell me.

I’m also not sure what would be needed to debug this, so please tell me what logs or similar could be useful.

$ uname -a
Linux 5.7.14-200.fc32.x86_64 #1 SMP Fri Aug 7 23:16:37 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ zathura --version
zathura 0.4.5
girara 0.3.4 (runtime: 0.3.4)
(plugin) pdf-mupdf (0.3.5) (/usr/lib64/zathura/libpdf-mupdf.so)
$ okular --version
okular 1.9.3
$ atril --version
MATE Document Viewer 1.24.0
1 Like
#3

I had a similar issue recently and it turned out I had to increase the number of inotify watchers in the kernel. Something, I think dropbox, was using up a majority of the quota and not leaving enough of them for the PDF viewers to use (i use zathura).

Take a look at this post. It’s a minor tweak and worth a quick check to see if increasing the limits fixes the issue:

3 Likes
#4

Same with both of them :confused:

1 Like
#5

Thanks, I tried to raise it and now it seems to work.

Have not figured out what it was that used up all watchers, but could very well be the Dropbox or Nextcloud client for me as well.

I think this also solved another problem I have had with VSCode where it complained it could not watch large directories which I have just ignored, but now it is gone.

2 Likes
#6

Looks like Dropbox is a common culprit. The folks on the stack exchange thread also mention it in comments.

Also listed in the answer is this command to check what is using the inotify watches. Pasting here for convenience:

find /proc/*/fd -lname anon_inode:inotify |
   cut -d/ -f3 |
   xargs -I '{}' -- ps --no-headers -o '%p %U %c' -p '{}' |
   uniq -c |
   sort -nr

Note: shows number of inotify file descriptors, but not watches, so may not be as helpful as I though.

1 Like
#7

Yeah, exactly.

Got me a bit confused when I had 8192 watches and that command summed up to ~80 things. But still good to get an overview of what things are using them at all.

1 Like