cat, pipe, and acroread – why is it failing occasionally? – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.
But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, shell, pdf, , .
in a simple shell script I’m trying to run this command:
cat /filelocation/myoutput.PDF | /opt/Adobe/Acrobat7.0/bin/acroread -toPostScript
Under most circumstances this is working. Occasionally however, I’m getting an error:
lp: standard input is empty lp: request not accepted Broken pipe cat: Cannot write to output.
This seems to occur only under heavy loads where we’re processing an extensive amount of pdfs recursively. (calling said shell command over and over with different files)
You could make your shell script even simpler and see if you at least get better error messages out:
/opt/Adobe/Acrobat7.0/bin/acroread -toPostScript < /filelocation/myoutput.PDF
This also makes the suggested strace a little nicer:
strace -f -o /tmp/acroread.$$.strace /opt/Adobe/Acrobat7.0/bin/acroread -toPostScript < /filelocation/myoutput.PDF
You can try using pdf2ps:
pdf2ps [ options ] input.pdf [output.ps]
Or, you may want to install a newer version of Adobe Acrobat.
I assume that since you’re using the
STDIN version of
-toPostScript that you’re piping to the output of
lp (not shown in the question?). I have a feeling you’re hitting a spooling issue — either you’re filling up the spool entirely (which causes
lp to barf) or hitting some other kind of limit.
This thread discusses some diagnostics for being unable to print a large file (though I suspect printing many small files in quick succession can cause the same ailments) —
- Check if your /var/spool/lp has enough free space.
- Assuming that /var/spool is the mount point, check if this filesystem has the “largefiles” option turned on. (Probably not applicable to your situation).
I don’t know much of anything about printing, but I definitely think it’s
lp that’s causing the problem, not
acroread or pipes in general. (Though, if you suspect
acroread you can try
pdf2ps, a utility that comes with
This would happen is acroread died before it sent any output. Without finding out why it died, you don’t have chance of fixing it. Given it’s closed source, the only thing you can do is try using strace to see what it’s doing when it dies.
cat /filelocation/myoutput.PDF | strace -f -o /tmp/acroread.$$.strace /opt/Adobe/Acrobat7.0/bin/acroread -toPostScript
This will make acroread a lot slower, but hopefully will make it fail at lower loads, so it should be quicker to see what is causing the problem. Note this uses $$ to use the process id of the script. If you call this more than once from the same script, you’ll need to find some other way of using different files.