One of the remaining things that needs to be fixed is LaTeX support on the blog, and I’d appreciate a little help to solve a problem.
The problem is that although LaTeX is installed properly, and the Latexrender plug-in is installed, the call to /usr/bin/latex does not work. So what happens when someone puts [ tex]E = mc^2[ /tex] is that the plug-in correctly creates a LaTeX document in a tmp folder as its supposed to.
But then the php script calls /usr/bin/latex it fails to find it. Now /usr/bin/latex exists and if you run the /usr/bin/latex .tex as root then it produces the .aux, .dvi and .log files as it should. But the script does not work on its own, which suggests that either apache somehow does not have rights to run /usr/bin/latex (which is chmod 755 by the way) or php is prevented from calling /usr/bin/latex
Has anyone any idea of where to look or encountered this problem before? Any helpful suggestions gratefully received.
The CA server is running CentOS 4.4 by the way.
22 Comments
Have you tried a command like:
su apache /usr/bin/latex …
(you may need to edit /etc/passwd to give the user apache a shell, temporarily, before you’re allowed to do this)
That way, if it’s outputting an error message (e.g. can’t access some file), you’ll be able to see what it is.
Alternatively check the apache error_log file, error messages output from commands spawned inside apache processes sometimes goes there.
Let me know how that goes, if that doesn’t work I’ll probably have some more ideas for you.
su apache /usr/bin/latex [name of file].tex
gives “cannot execute binary file”
John, probably not relevant, but I noticed this comment was giving a latex error. The document from which it was copied is using an “img src …” tag, so I’m not sure how it is getting into the latex machine.
fFred, it’s the same problem.
John A, not related to LATEX but still an issue with the forum is the text entry area when using IE6. The entry area wraps well past the recent comments area on the right and makes it difficult to post as you can’t scroll over that area.
It doesn’t on IE7.
chroot?
Go on….
John A, is /usr/bin/latex a binary executable or script file? Perhaps open it in a text editor to find out.
If it’s a script file, it may be missing the #! line at the beginning, or that line may be referencing an interpreter which apache is not able to access.
If it’s a binary executable, I’d check the shared libraries it requires and that the apache user can access them. Something like:
su apache ldd -r /usr/bin/latex
will be enlightening, assuming it’s a binary. If it’s a script then you need to make sure that the apache user (a) can execute the script program properly and (b) that’s correctly specified in the head of the file.
I’ll install latex (which is rather large, so it’ll take a little while to download) and have a look at /usr/bin/latex to get some additional clues..
OK, here is what I have. /usr/bin/latex is a link:
ls -al /usr/bin/latex
lrwxrwxrwx 1 root root 7 Jan 13 18:49 /usr/bin/latex -> pdfetex
pdfetex is a binary executable:
file /usr/bin/pdfetex
/usr/bin/pdfetex: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped
It may be different on your system. Strangely, even if I try to run that binary in 32 bit mode, I don’t get the error you get. I’ll investigate that error message a little more. Most of what I’ve found so far is related to scripting problems, so maybe your latex executable really is a script… (what package did you install to get it?)
John, a quick thought, when you test latex as root, do you do so with the full path, i.e. /usr/bin/latex?
If not, perhaps there is a /usr/local/bin/latex and that works, but /usr/bin/latex doesn’t? (“which latex” should help)
One reason you’d get “cannot execute binary file” is if the file is for the wrong architecture, or somehow corrupt. But if that’s the case you should get it as root too.
Nicholas,
I think its simply that Apache is not allowing binary executables to be run. I just need to work out where its doing that. It’s a setup I inherited from webserve.ca which is doing this. My near identical setup on auditblogs.com does not have this issue.
The other fun is that there is a fiendish number of conf files to look through to work out what the end result should be.
Oh, check /etc/security/*.conf
That’s where per-user limits are usually configured. Perhaps by default your system limits the permissions of the apache user, or perhaps it limits the memory of child processes so aggressively that they can’t run latex. That’s where I’d look first.
Here’s what the error_log says, when I try to use latex:
Yet the script clearly points to /usr/bin/latex. I wonder if Apache has been configured to ignore directory structure outside of its home directory?
Did you check in /etc/security/ whether the apache user is set to have a chroot? I’d also check the apache configuration. That’s what it sounds like to me.
It might be simpler if you copied /usr/bin/latex into the apache home directory and pointed it at that.
I checked and chroot contains just comments and no reference to the apache user or group. By the way /usr/bin/latex is a softlink, not a script.
OK, well that doesn’t explain the “/latex” path then. That must have something to do with the apache configuration. Is chroot or any special scripting stuff enabled in apache?
chroot? no.
special scripting? I don’t know.
#6, Yes, it works fine on IE 7 but not on IE6. I don’t have IE 7 and I’m sure a number of other people don’t have it either. It’s not a huge deal, but it is a bit frustrating to deal with.
John A said
As others suggest above:
(1) the server may be running against a restricted file system. If you can get the output from your web server’s idea of ‘ls -id /’ and compare that against what you see when testing that should tell you definitively. (Your hosting service could chroot you without letting you know.)
(2) Apache can be configured to refuse to follow symbolic links in a number of circumstances. As you say, chasing down the configuration can be painful.
I hope everyone sees the irony here. We are told to accept the computer models of GCMs as accurate predictions. However the state of “software engineering” is that it is difficult to put together a simple application out of supposedly working and debugged components. Earlier Martin Juckes was embarrassed when the Linux distribution her had been supplied with reacted to an inability to access data from a network file by simply returning false data. Now we have the Latex mystery. Everything works but nothing works – The standard state of software.
Climate modelers should admit that they have no idea what is happening in the bowels of their computer coded. They are getting results but whether or not these results come from their design or from a set of unknown bugs, is something that they cannot tell with certainty.
Jo Calder:
Painful is right. I’m going to write to webserve.ca’s support asking them about what it is they actually supplied.