0

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)

Matt Simmons
  • 20,396
  • 10
  • 68
  • 116
  • Does this happen when the command is first executed, or in the middle while processing a file? – Matt Simmons Jun 05 '09 at 16:39
  • I'll have to check; I am 95% certain it's in the middle of a run, like the 33rd file to process or something like that. –  Jun 05 '09 at 16:40
  • What I mean is that is it happening at the beginning of the 33rd file or the middle of the 33rd file? Have you watched the memory as the process executes? – Matt Simmons Jun 05 '09 at 16:44
  • Oh, I see. Unknown currently, I haven't watched memory as the process executes. Will be the next step; we've rewritten it with some return value checking and conservative retries to see if it alleviates the problem. If not, we're moving forward with watching memory. –  Jun 05 '09 at 20:03
  • Is there any reason why you are doing this instead of using the pdf2ps command (part of the ghostscript package)? – dkaylor Jun 06 '09 at 02:07

5 Answers5

1

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
pjz
  • 10,595
  • 1
  • 32
  • 40
1

You can try using pdf2ps:

pdf2ps [ options ] input.pdf [output.ps]

Or, you may want to install a newer version of Adobe Acrobat.

yadimka
  • 154
  • 2
1

I assume that since you're using the STDOUT/STDIN version of -toPostScript that you're piping to the output of acroread to 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 cat, acroread or pipes in general. (Though, if you suspect acroread you can try pdf2ps, a utility that comes with xpdf).

hark
  • 560
  • 2
  • 6
0

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.

David Pashley
  • 23,497
  • 2
  • 46
  • 73
0

This is probably happening if the pipes haven't been closed properly and are trying to reopen. This could happen if you're under heavy load, like you say you are.

Try introducing a slowing factor between calls. Maybe throw a 'wait 1' command in there between calls to your script.

  • The only pipes here are unnamed: they've never been opened it nor closed them prior to present use, because they've just been created and nobody else can see them. –  Jun 05 '09 at 17:21
  • I know, but I'm talking about possible overload on the operating system. –  Jun 05 '09 at 17:23
  • sleep 1, right? Wouldn't wait 1 do nothing unless there's a PID of 1? Or am I missing some PID functionality? –  Jun 05 '09 at 20:05