My document includes several PDF files generated by PlantUML. These files are stored in different directories underneath the document directory. So far, I've created these files with a combination of shell scripts and Makefiles. Today I learned about latexmk's custom dependencies.

I've added the following to my .latexmkrc:

add_cus_dep('puml', 'pdf', 0, 'puml2pdf');
sub puml2pdf {   system( "plantuml -Djava.awt.headless=true -charset UTF-8 -tpdf \"$_[0].puml\" \"$_[0].pdf\" "); }

Now latexmk should detect a missing PDF file on the first run and the custom dependency should kick in to run plantuml as defined. Unfortunately, it doesn't. lualatex fails with an error and the custom dependency is never written to the .fls file:

LaTeX Warning: File `signservice_isignaturecore.pdf' not found on input line 529.

! Package luatex.def Error: File `signservice_isignaturecore.pdf' not found: using draft setting.

See the luatex.def package documentation for explanation.
Type  H <return>  for immediate help.

l.529 ...sinf.opmon.ieventsenderforoperationmonitor}

Try typing  <return>  to proceed.
If that doesn't work, type  X <return>  to quit.

! Output loop---200 consecutive dead cycles.
\AP@clearpage ...e \m@ne {}\vbox {}\penalty -\@Mi

l.529 ...sinf.opmon.ieventsenderforoperationmonitor}

I've concluded that your \output is awry; it never does a
\shipout, so I'm shipping \box\outputbox out myself. Next time
increase \maxdeadcycles if you want me to be more patient!

The error probably results from the following construction in which I rotate the page and try to make sure that the float isn't placed too far way from text where it is referenced:

  \clearpage% Flush earlier floats (otherwise order might not be correct)
  \begin{landscape}% Landscape page
    \centering % Center table
          \caption{Klassenhierarchie für \java{IsignatureCore}}
  \clearpage% Flush page

Now two questions arise:

  • How can I convince latexmk to write the missing dependency to the .fls file despite the error?

  • Is it correct that in order to make latexmk recognize the dependency in the first place, it must be started in -silent mode, otherwise lualatex halts and requires user input. In this case, latexmk can't be used in a CI/CD environment without user interaction.

  • You've got very much worse problems than latexmk not running the custom dependency. 1. There is a very unusual error message from lualatex about ! Output loop---200 consecutive dead cycles. 2. The extract that lualatex prints from line 529 has nothing in common with the document code extract that you show. There is clearly a problem caused by something else in your document. You need to sort that out first: E.g., comment out the \includegraphics line; I predict you will still get errors. Only worry about the custom dependency after the document is corrected. Apr 26, 2023 at 20:48
  • Addendum to your second question: To avoid the need for user input, you can also use the option -interaction=batchmode to latexmk. That is often better than just using the -silent option if you are debugging problems. That's because the -silent option also causes latexmk to reduce the number of messages it writes, and these likely to be relevant to debugging. Apr 26, 2023 at 20:58
  • The .fls file is not the place to determine whether the custom dependencies are run. That file is lualatex's record of files it reads and writes. The information about custom dependencies is in the .fdb_latexmk file. There's no need for anything to be written to the .fls file about the missing dependency; lualatex writes an appropriate message to the .log file, and latexmk reads that message. You can look at the .log file and search for the message. But with other errors you get, I would worry that the .log file is incompletely written by lualatex. Apr 26, 2023 at 21:06
  • I've found a convenient way to check whether the expected programs were run is to give the -time option to latexmk. That causes latexmk to give an end-of-run summary of what it ran (together with the timings). Apr 26, 2023 at 21:09
  • Thanks, @JohnCollins, for all the information. This really helped to set my thoughts straight and to figure out the solution for the problem. Apr 28, 2023 at 10:04

1 Answer 1


It turned out that latexmk wasn't picking up the dependencies properly to run the custom rule. This happened because the \includegraphics commands didn't include the whole path to the PDF file. This was unnecessary before, because of the \graphicspath macro at the top of the file. Of course, latexmk didn't know about the \graphicspath, so it wasn't able to calculate the correct location of the source file for the PDF. Once I've changed that, the correct source files were found and latexmk could call the custom dependency.

You must log in to answer this question.

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