TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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 Nov 29 '11 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 Nov 29 '11 at 19:25
@egreg Is there a bug report or any other resource that notes that behavior? – N.N. Nov 29 '11 at 21:04
@N.N. No, it's a behavior that I've noticed from time to time, particularly with beamer failed compilations. – egreg Nov 29 '11 at 22:14

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.

share|improve this answer
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 Nov 30 '11 at 6:01
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 Oct 13 '13 at 17:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.