From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705) Description of problem: 'gs' hangs up executing 'gs -q -sDEVICE=pdfwrite - sOutputFile=archoverview.pdf - -c quit < gspipe.input' Looking at the system trace I've found it's because of reading from /dev/random: strace -o gs.log gs -q -sDEVICE=pdfwrite - sOutputFile=archoverview.pdf - -c quit < gspipe.input Here is a piece of qs.log: .... open("/dev/random", O_RDONLY) = 13 fstat64(13, {st_mode=S_IFCHR|0644, st_rdev=makedev(1, 8), ...}) = 0 ioctl(13, TCGETS, 0xbfff9318) = -1 EINVAL (Invalid argument) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, - 1, 0) = 0xb75e5000 read(13, 0xb75e5000, 4096) = ? ERESTARTSYS (To be restarted) --- SIGINT (Interrupt) @ 0 (0) --- +++ killed by SIGINT +++ Initially the problem came up from the epstopdf PERL script (package tetex-1.0.7-66). I reproduced it on one machine which has EL AS 3 (Taroon) installed. But it isn't reproducible on another one. What the problem it can be ? Version-Release number of selected component (if applicable): ghostscript-7.05-32.1.8 How reproducible: Sometimes Steps to Reproduce: 1. gs -q -sDEVICE=pdfwrite -sOutputFile=archoverview.pdf - -c quit < gspipe.input Actual Results: It just hangs up. Expected Results: archoverview.pdf should be created Additional info:
See bug #97583.
This has been fixed in CVS but isn't yet scheduled to be made an official update. *** This bug has been marked as a duplicate of 97583 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.