latexmk has suddenly stopped working (version 1:4.41-1 under Ubuntu 16.04.1 with texlive-full from the Ubuntu repos) and "Perl 5, version 22, subversion 1 (v5.22.1) built for x86_64-linux-gnu-thread-multi"

No matter what options I use, it dies instantly with:

Insecure dependency in eval while running setgid at /usr/bin/latexmk line 3193, <GEN0> chunk 1.

Adding the -diagnostics option does not provide any additional information. I don't know enough Perl to understand what it's doing at line 3193, but it looks like it's trying to find the .latexmkrc file and failing to perform the open() because it thinks it's a security risk.

my $RCH = new FileHandle;
if ( !-e $rc_file ) {
    warn "$My_name: The rc-file '$rc_file' does not exist\n";
    return 1;
elsif ( -d $rc_file ) {
    warn "$My_name: The supposed rc-file '$rc_file' is a directory; but it\n",
         "          should be a normal text file\n";
    return 1;
elsif ( open $RCH, "<$rc_file" ) {
    { local $/; eval <$RCH>; } #### This is line 3193
    close $RCH;
else {
    warn "$My_name: I cannot read the rc-file '$rc_file'\n";
    return 1;

Has anyone else had this problem, or got any indication of what it might be doing? I have latexmk running happily on all my other platforms.


  • You might want to list your Perl version as well. Are you running latexmk under some web process? Looks odd to get a setgid error
    – daleif
    Dec 8, 2016 at 12:58
  • To amplify the comments by @daleif At the line you indicated, latexmk is trying to execute Perl code in one of its configuration "rc" files. That is not allowed when Perl has its tainting mechanism turned on. According to the Perl documentation that is either because latexmk is running setuid or setgid or when taint mode is specified by a -T option on the command line for Perl. This suggests that something has changed in the way your latexmk is getting invoked. Dec 12, 2016 at 14:59
  • A possible clue: In the version of latexmk 4.41 that I released, line 3193 is not the one you indicated; this suggests your latexmk.pl is modified. The file in Ubuntu 16.04.1 at launchpad.net/ubuntu/+source/latexmk/1:4.41-1 is identical to my released version at personal.psu.edu/jcc8/latexmk/versions.html. Could you compare your latexmk with the original. The difference might well be in the first few lines. Dec 12, 2016 at 15:04
  • Edited to show Perl version. No mods or extra options are used: I run latexmk from a Makefile, but it gives the same error when run manually from the command line. It's all stock, as installed from the repos, no mods of any kind, but I'll certainly check it against the version you specified, thanks. Dec 13, 2016 at 11:02
  • Plot thickens...I downloaded latexmk_4.41.orig.tar.gz from Launchpad and when I run latexmk.pl, I get Latexmk: This is Latexmk, John Collins, 1 January 2015, version: 4.41. Latexmk: Index file 'directory.idx' was written Latexmk: Log file says output to 'directory.pdf' Insecure $ENV{PATH} while running setgid at /tmp/latexmk.pl line 7821. The diff is 937,938c937 < ( "/etc/$_", < "/opt/local/share/latexmk/$_", --- > ( "/opt/local/share/latexmk/$_", Dec 13, 2016 at 13:03

1 Answer 1


I discovered that the setuid bit had been set on the directory above the one where latexmk had been installed. Clearing that fixed the problem (and has probably broken something else, but that's another day's work).

How do I mark this as Solved?

  • You accept an answer (presumably yours) by clicking the greyed-out tick at its top left. Where on earth is latexmk installed that its containing directory has the setuid bit set? It would worry me that this was set.
    – cfr
    Jan 15, 2017 at 2:38
  • It puzzles me too, as it's in the normal place, /usr/bin. It was the bin directory that had the setuid set. It's conceivable that it was finger slippage. Jan 15, 2017 at 20:24
  • I would check the permissions for all system directories and their contents. Or reinstall the standard ones. Your distro probably provides a straightforward way to do this. Whether setuid on a directory does anything is, according to the man pages, dependent on how the system is configured. But the fact that that is set on /usr/bin is weird. And it is hard to see how you could do it yourself accidentally unless you are fine-tuning ownership and permissions on system files, in which case, you presumably know what you are doing.
    – cfr
    Jan 15, 2017 at 22:59
  • I checked my .bash_history and it was indeed finger slippage some time ago. I was probably trying to set the setuid bit on ~/bin but typed /usr/bin instead. Age and decrepitude, I expect. Jan 18, 2017 at 22:43
  • That should be hard to do. If I'm setting stuff on ~/bin, I'm not using a privileged account or privilege escalation, so if I do it on /usr/bin by mistake, I'll just get a error due to lack of permissions.
    – cfr
    Jan 19, 2017 at 0:27

You must log in to answer this question.

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