He estado usando felizmente scanadflos -S script --script-wait
parámetros durante un par de años.
Mi secuencia de comandos, llamada scan_perpage, convierte los datos de la imagen a pdf, mediante una llamada a pnmtops, canalizada ps2pdf.
Sin embargo, recientemente (sospecho que desde que actualicé Fedora 17 a 19), el script llamado se bloquea y, por lo tanto, scanadfse bloquea. El guión se cuelga con el pnmtopscomando. El pnmtopscomando en sí está esperando a que se complete su filtro de salida "secundario" bifurcado pnmtops, y nunca lo hace.
Ejecutar el scan_perpagescript directamente en la salida de la página sin formato del escáner funciona bien. Ejecutar el pnmtopscomando directamente también funciona bien. Sólo cuando se ejecuta desde scanadfvía -Sel script se bloquea en pnmtops.
Versiones:
# 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
Aquí está el resultado de mi scanscript, que llama scanadf -vv:
$ scan -o output.pdf
Scanning...
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>
Aquí está el árbol de procesos en el punto de colgar:
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
El proceso 10904 (el pnmtops"filtro de salida" bifurcado) nunca finaliza. Una pista indica que está esperando una "lectura".
No puedo entender por qué pnmtopsse bloquea cuando se llama a través de scanadf, pero cuando se llama directamente en el mismo archivo, funciona perfectamente bien.
Además, si el pnmtopssubproceso se mata manualmente, todo continúa sin ningún problema.
Respuesta1
De Bryan Henderson, mantenedor de netpbm:
Encontré y solucioné un error que causa este síntoma. [...] La solución está en Netpbm 10.64.02.
La diferencia en el entorno que hace que Pnmtops a veces se bloquee y otras no es la cantidad de archivos abiertos. Si hay más de 10 archivos abiertos cuando se invoca Pnmtops, se produce el bloqueo.
En caso de que le importe cuál es la patología: el niño sale cuando la tubería que lo alimenta indica EOF. Eso sucede cuando se cierra cada copia del descriptor de archivo para el extremo de envío de la tubería. La única copia que se supone que existe es aquella en la que el proceso principal escribe datos. Pero el niño necesariamente hereda copias de los descriptores de archivo para ambos extremos de la tubería. Si el niño no cierra su copia del enviandoAl final de la tubería, el niño nunca verá EOF en el extremo receptor, por lo que esperará para siempre.
Eso significa que el niño debe cerrar su copia del extremo emisor del tubo que lo alimenta. Para hacer esto y solucionar algunos otros problemas similares, el niño intenta al inicio cerrar todos los descriptores de archivos además de los dos que realmente usa. Pero POSIX no proporciona una manera de conocer la lista de descriptores de archivos abiertos, por lo que el niño simplemente cierra ciegamente 0-9 (excluyendo los dos que necesita), sabiendo que Pnmtops no usaría más archivos que ese. El error fue que el programa no tuvo en cuenta los descriptores de archivos con los que nació el proceso. La solución es que Pnmtops cierre los descriptores de archivos 0-9 cuando se inicia, de modo que cualquier canal que cree tendrá números de descriptores de archivos en el rango 0-9 y, por lo tanto, se cerrará con el cierre ciego 0-9.