latexmk is the tool I'm using to compile my documents, and the -pvc option is the one which is normally on. In this setting, when I save a file which produces a compilation error, then latexmk informs that there was an error and the document is not being updated in the viewer (skim in my case). Once I correct the problem in the .tex file, latexmk kicks in again, and resumes its activity. In particular, the open document is refreshed correctly.

Problem occurred to me, when I use the setting mentioned above, when trying to compile a beamer's class document (and if it makes any difference, using the beamerposter package). In this case, when compiling a file with a mistake in it, then latexmk will report the problem and the document won't update as before. However, once I correct the problem in the source, latexmk recompiles, and produces the correct .pdf file, but the link to the open document breaks, and I have to reopen it manually... In other words, the document which was open, is dead and doesn't "see" the updated version which was created after the correction of the mistake.

Do you have any idea how to handle this? Where to look for a solution?


I have just realized that the same problem happens also when compiling sources not using beamer. The cause this time might be the tikz graphics. Any ideas?

Edit 2 - Possible way out:

Skim offers the revert option, which seems to fix the broken linkage between skim and the damaged/badly-processed pdf. Can you think of a way to turn this clue into a full solution?

  • 1
    It happens sometimes that Skim loses track of the file to update and I don't think there's much to do than closing the old window.
    – egreg
    Commented Nov 29, 2011 at 17:29
  • This is my hunch as well, it's only I also suspect it has to do with the way latexmk corrupts the .pdf while compiling a source which contains an error.
    – Dror
    Commented Nov 29, 2011 at 19:25
  • @egreg Is there a bug report or any other resource that notes that behavior?
    – N.N.
    Commented Nov 29, 2011 at 21:04
  • @N.N. No, it's a behavior that I've noticed from time to time, particularly with beamer failed compilations.
    – egreg
    Commented Nov 29, 2011 at 22:14

2 Answers 2


The problem is not specific for latexmk, but related to Skim, the way pdflatex works and how file notifications are implemented in OSX (and its Mach kernel under the hood).

  • The problem is that pdflatex does not change the PDF file in an atomic manner, but during the compilation process more or less continuously updates bits and bytes inside it.

  • The file system notices the writes to the file and sends an update notification to the monitoring Skim process. It uses some heuristics to not send an update event for every single changed byte (which would be very inefficient). The common approach here is to delay the update notification until no new changes have shown up for some time (usually a couple of milliseconds).

  • If this heuristic interacts badly with the write pattern of pdflatex, Skim gets notified before the PDF is ready and tries to read a not-yet complete PDF file. However, Skim is not well prepared for this, which result in all sorts of problems: from strange error messages over crashes to a lost of the notification handle. The last is the behaviour you observe.

  • The problem should not per se be bound to specific document classes, such as beamer. However, I also observed it especially in conjunction with beamer. My assumption is that when compiling beamer documents, pdflatex has usually to generate a whole extra bunch of files (all that .toc, .vrb, .nav, .snm files) and in between also spends relatively much computing time. As a result, updates to the PDF file during compilation are less frequent, which increases the probability of a bad interaction with the file system's heuristic to send change notifiations.

My personal solution to the problem is to add another level of indirection: Whenever the command to build the final PDF (I use pdflatex directly or rubber) has terminated successfully, I copy the resulting document.pdf to a document-view.pdf, which is the file I have open in Skim. The copying happens more or less instantaneous, the update mechanism works fine.

I personally use a Makefile for this task in combination with a small Ruby script that observes the source files to invoke make whenever a source file has changed. To integrate such behavior into latexmk one probably has to hack a bit around with the tool settings in latexmkrc (e.g., setting $pdf_previewer='cp %S %S-view.pdf'). However, my experience with latexmk is limited and I have not tested this.

  • This sounds like the problem's root. I tried your idea with the $pdf_viewer but it didn't work. latexmk has the option $always_view_file_via_temporary [1]; but it doesn't work with pdflatex. Do you or anyone else have further ideas?
    – Dror
    Commented Nov 30, 2011 at 6:01
  • 1
    For the $pdf_viewer approach to work, you also need to add $pdf_update_method = 4;. I can confirm that it works (with evince as viewer).
    – hannes
    Commented Oct 13, 2013 at 17:02

First of all, check out out Daniel's excellent answer on the background of this problem.

In case this is still relevant for anybody, here is an example latexmkrc which should solve the problem in combination with Skim.
Note: It relies on a custom update command to Skim once the LaTeX compilation is finished and therefore you need to disable the automatic reload of a file in Skim itself (check https://sourceforge.net/p/skim-app/wiki/TeX_and_PDF_Synchronization/#reload-updated-pdf-files for further information)

$pdf_mode = 1;
$pdf_previewer = 'open -a Skim';
$pdflatex = 'pdflatex -synctex=1 -interaction=nonstopmode';

# -- Custom update command --
$pdf_update_method = 4;
$pdf_update_command = 'file=%S; [ "${file:0:1}" == "/" ] || file="${PWD}/${file}"; \
/usr/bin/osascript << EOF
set theFile to POSIX file "${file}" as alias
tell application "Skim"
set theDocs to get documents whose path is (get POSIX path of theFile)
if (count of theDocs) > 0 then revert theDocs
open theFile
end tell
# -- End of custom update command --

@generated_exts = (@generated_exts, 'synctex.gz');

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .