Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have been happily using scanadf with the -S script --script-wait parameters for a couple of years.

My script, called scan_perpage, converts the image data to pdf, via a call to pnmtops, piped through ps2pdf.

However recently (I suspect since I updated from Fedora 17 to 19), the called script hangs, and therefore scanadf hangs. The script is hung at the pnmtops command. The pnmtops command itself is waiting for its forked "child" pnmtops output filter to complete, and it never does.

Running the scan_perpage script directly on the raw scanner page output works fine. Running the pnmtops command directly also works fine. It is only when run from scanadf via -S that the script hangs at pnmtops.


# rpm -q --info sane-backends
Name        : sane-backends
Version     : 1.0.23
Release     : 13.fc19

# rpm -q --info sane-frontends
Name        : sane-frontends
Version     : 1.0.14
Release     : 16.fc19

# rpm -q --info netpbm
Name        : netpbm
Version     : 10.61.02
Release     : 5.fc19

Here is the output of my scan script, which calls scanadf -vv:

$ scan -o output.pdf
scanadf: value for --resolution is: 300
scanadf: scanning image of size 2544x3300 pixels at 1 bits/pixel
scanadf: acquiring gray frame
Started script `/usr/local/bin/scan_perpage' as pid=10902
Scanned document scan-0001
pnmtops: Input maxval is 1.  Postscript raster will have 1 bits per
sample, so maxval = 1
pnmtops: Image will be 610.56 points wide by 792.00 points high, left
edge 0.72 points from left edge of page, bottom edge 0.00 points from
bottom of page; NOT turned to landscape orientation
pnmtops: output filter spawned: pid 10904
pnmtops: Waiting for PID 10904 to exit
Scanned 1 pages
<the script hangs here>

Here is the process tree at the point of the hang:

10897 32072 /bin/sh /usr/local/bin/scan -o output.pdf
10898 10897 scanadf -vvv -d fujitsu -S /usr/local/bin/scan_perpage
--script-wait --resolution 300 --mode Lineart -o scan-%04d
10902 10898 /bin/bash /usr/local/bin/scan_perpage scan-0001
10903 10902 pnmtops -verbose -imagewidth 8.5 -imageheight 11 scan-0001
10904 10903 pnmtops -verbose -imagewidth 8.5 -imageheight 11 scan-0001

Process 10904 (the forked pnmtops "output filter") never finishes. An strace indicates it is waiting on a "read".

I can't figure out why pnmtops hangs when called via scanadf, but when called directly on the same file it works perfectly fine.

In addition, if the pnmtops subprocess is killed manually, everything continues without any problem.

share|improve this question
up vote 0 down vote accepted

From Bryan Henderson, maintainer of netpbm:

I found and fixed a bug that causes this symptom. [...] The fix is in Netpbm 10.64.02.

The difference in environment that causes Pnmtops sometimes to hang and sometimes not is the number of open files. If there are more than 10 open files when Pnmtops gets invoked, the hang happens.

In case you care what the pathology is: The child exits when the pipe feeding it signals EOF. That happens when every copy of the file descriptor for the sending end of the pipe closes. The only copy that's supposed to exist is the one the parent process is writing data to. But the child necessarily inherits copies of the file descriptors for both ends of the pipe. If the child doesn't close its copy of the sending end of the pipe, the child will never see EOF on the receiving end, so will wait forever.

That means the child must close its copy of the sending end of the pipe that is feeding it. To do this, and fix some other similar problems, the child attempts at startup to close every file descriptor besides the two it actually uses. But POSIX doesn't provide a way to know the list of open file descriptors, so the child just blindly closes 0-9 (excluding the two it needs), knowing that Pnmtops would not use more files than that. The mistake was that the program didn't account for file descriptors the process was born with. The fix is for Pnmtops to close file descriptors 0-9 when it starts up, so that any pipes it creates will have file descriptor numbers in the range 0-9 and thus get closed by the blind 0-9 close.

share|improve this answer
The Fedora Bugzilla bug associated with this: bugzilla.redhat.com/show_bug.cgi?id=1029512 – Raman Nov 14 '13 at 6:04

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.