Red Hat Bugzilla – Bug 64952
mf_wrapper error "/dev/stdin: No such device or address"
Last modified: 2007-04-18 12:42:35 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 Description of problem: Printing to a JetDirect-attached LaserJet fails with a "/dev/stdin: No such device or address" error in mf_wrapper. The control and data files of the job to be printed remain in the printer's spool directory. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Do a clean install of 7.3 2.Use printconf-tui to import the attached printer definition 3.Print something 4.Nothing prints (lpq at first shows "waiting for printer filter to exit"; this changes to "job XXX saved at HH:MM" Actual Results: The job doesn't print. The file /var/spool/"quename"/lpq.0 includes the line: Status: IF filter 'mf_wrapper' filter msg - '/usr/share/printconf/util/mf_wrapper: /dev/stdin: No such device or address' at 15:16:20.452 (All one line, of course) The control and data files for the job remain in the printer's spool file. Expected Results: The job should've printed, with the job's control and data files being removed after the job completes. Additional info: I confirmed that the line in mf_wrapper causing the error message is this one: /usr/bin/magicfilter-t "$TMP_FILE" $DEBUGSTRING < /dev/stdin Adding "ls" commands to mf_wrapper showed /dev/stdin looking reasonable.
Created attachment 57344 [details] Printer setting XML for printconf
Does changing that line to: /usr/bin/magicfilter-t "$TMP_FILE" $DEBUGSTRING help any?
That changed the footprint, but not the basic problem. lpq used to show "waiting for printer filter to exit" for about a minute, then "job 'blah' saved at 'time'". Now lpq shows "processing 'blah', size 18052, format 'f', IF filter 'mf_wrapper' at 10:26:27.713" for about a minute, then the same "job saved" status. In both cases, the job remains on queue. I'll attach two copies of lpq.0 -- one without the mf_wrapper modification, and the other with the modification. I don't know if these will help, but there's a whole bunch of stuff in there that maybe you'll understand more than I do... :-)
Created attachment 57586 [details] lpq.0 output with original mf_wrapper file (queue empty at job start)
Created attachment 57587 [details] lpq.0 output with modified mf_wrapper (queue empty at job start)
'lpq.0 output with modified mf_wrapper' looks like a normal termination. If nothing comes out of the printer we might be looking at a different problem now.
Just for grins, I manually ran /usr/share/printconf/util/jetdirectprint, and typed in "This is a test". Shortly after, "This is a test" was printed on the printer. So it looks like all the pieces work individually, but not when they're used together... :-\
But echo "This is a test" | lpr doesn't work? What type of things have you tried printing via lpr?
Nope, 'echo "this is a test" | lpr' doesn't work with either the original or the modified mf_wrapper. I have tried printing the printconf postscript test page, and my .bashrc -- both with the same result...
Did it work on 7.2+updates?
Yes, no problems at all until I installed 7.3...
Can you try downgrading to printconf-0.3.61-3 and printconf-gui-0.3.61-3 and let me know if that works around the problem? If so we can do a binary search between 0.3.61 and 0.3.77 to find out where it broke and how. Thanks.
I ran into this on one of our machines that was recently upgraded to 7.3. The actual printer is connected to another machine running 7.2 with all patches (as of about a month ago) applied. We had no problems with printing from the 7.2 machine; however, now, after the problems w/ the 7.3 showed up, printing is no longer working on the 7.2 machine. I've tried doing a clean re-install of the printer on the 7.2 machine with no effect. The problem is the same as on the 7.3 machine: /usr/share/printconf/util/mf_wrapper: /dev/stdin: No such device or address. Printconf on the 7.2 machine is printconf-0.3.61-3
Further info: I have another machine which is also running 7.2, but does not suffer this problem - I set up the printer identically to how it is set up on the other 7.2 machine. Unfortunately, it is also running printconf-0.3.61-3, which suggests that this will be a little trickier to track down ;-) Any suggestions as to which details to look at to find out what's different between the two machines? For reference, here's the printcap, which is identical on both machines: galois-lj1:\ :ml=0:\ :mx=0:\ :sd=/var/spool/lpd/galois-lj1:\ :af=/var/spool/lpd/galois-lj1/galois-lj1.acct:\ :sh:\ :lp=|/usr/share/printconf/util/jetdirectprint:\ :lpd_bounce=true:\ :if=/usr/share/printconf/util/mf_wrapper:
The files to look at are /etc/alchemist/namespace/printconf/local.adl. If you attach them both to this bug report we'll have some more datapoints, and that's always useful.
*ping*
This problem is not just jetdirect connected printers, but rather any printer not using a "raw" driver. It is quite a showstopper. It appears have something to do with the /dev/stdin entry rather than the print spooler system. Take the following examples: I added the following 2 lines to the /usr/share/printconf/util/mf_wrapper file before the /usr/bin/magicfilter-t $TMP_FILE $DEBUGSTRING $* < /dev/stdin line as follows: cp $TMP_FILE /tmp/tmp.file.test cat /dev/stdin > /tmp/stdin.test /usr/bin/magicfilter-t $TMP_FILE $DEBUGSTRING $* < /dev/stdin I then issued the command: cal 2002 | lp -desp On both 7.2 and 7.3 systems /tmp/tmp.file.test was populated the same. but... on the 7.2 system the /tmp/stdin.test file contained the calendar on the 7.3 system the /tmp/stdin.test file was empty
bill@sweye.com: Does changing that line to: /usr/bin/magicfilter-t "$TMP_FILE" $DEBUGSTRING help any? See also the reply to this question dated 2002-05-16 10:43:22. Unfortunately, I haven't been able to reproduce this problem, try as I might. :-(
sorry to be so long to reply. One mistatement by me. on the 7.3 system the line was: /usr/bin/magicfilter-t $TMP_FILE $DEBUGSTRING < /dev/stdin rather than: /usr/bin/magicfilter-t $TMP_FILE $DEBUGSTRING $* < /dev/stdin I did try using: /usr/bin/magicfilter-t $TMP_FILE $DEBUGSTRING with the same results that were outlined earlier in this discussion by ed@redhat.com. It should be noted that I have tried this on 2 seperate machines, default install out of the box (store boxed copy) with the same results. I also tried downloading and installing printconf-0.3.77-1 and printconf-gui-0.3.77-1. This did not help.
So far we've had this: printconf-0.3.77-1: Failure (ed) printconf-0.3.77-1: Failure (jeff) printconf-0.3.77-1: Failure (bill) printconf-0.3.61-4.1: Success (ed) printconf-0.3.61-3: Failure (jeff) printconf-0.3.61-3: Success (jeff) Ed and Bill: Can you please try downgrading to 0.3.61-4.1 or 0.3.61-3 and confirm that it makes everything work again? (If not, the problem may be elsewhere.)
(There's no chance that it's a firewall problem is there?)
Please try the /usr/share/printconf/util/jetdirectprint from the printconf-0.4.10-1 package. I think (and hope) it may fix this problem.
I just *knew* this was going to happen... :-\ I had switched over to CUPS so that I could at least print stuff, and now (after switching back to LPRng), I can't replicate the problem -- everything prints just fine now. :-( That surprised me, because while we were originally working on this, I had switched between LPRng and CUPS several times a day, and LPRng would always exhibit the problem. I ended up trying the newer jetdirectprint, and it also worked, but without being able to replicate the problem, I have no way of knowing if it'll fix it. I didn't break it, though... :-) Ed
(Bugzilla didn't seem to mail me your comment.. odd.) Okay Ed, at least it works now for whatever reason(!). Bill or Jeff: are either of you still seeing this problem?
Using devfs, by any chance?
No feedback.