Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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)

share|improve this question
    
Does this happen when the command is first executed, or in the middle while processing a file? –  Matt Simmons Jun 5 '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. –  John Barry Jun 5 '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 5 '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. –  John Barry Jun 5 '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 6 '09 at 2:07

5 Answers 5

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).

share|improve this answer

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.

share|improve this answer
    
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. –  ephemient Jun 5 '09 at 17:21
    
I know, but I'm talking about possible overload on the operating system. –  samoz Jun 5 '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? –  John Barry Jun 5 '09 at 20:05

You can try using pdf2ps:

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

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

share|improve this answer

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
share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.