Bug 64952 - mf_wrapper error "/dev/stdin: No such device or address"
mf_wrapper error "/dev/stdin: No such device or address"
Product: Red Hat Linux
Classification: Retired
Component: printconf (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2002-05-14 20:18 EDT by Ed Bailey
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-16 12:37:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Printer setting XML for printconf (4.39 KB, application/octet-stream)
2002-05-14 20:20 EDT, Ed Bailey
no flags Details
lpq.0 output with original mf_wrapper file (queue empty at job start) (7.01 KB, text/plain)
2002-05-16 10:44 EDT, Ed Bailey
no flags Details
lpq.0 output with modified mf_wrapper (queue empty at job start) (4.99 KB, text/plain)
2002-05-16 10:45 EDT, Ed Bailey
no flags Details

  None (edit)
Description Ed Bailey 2002-05-14 20:18:33 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:

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

(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.
Comment 1 Ed Bailey 2002-05-14 20:20:49 EDT
Created attachment 57344 [details]
Printer setting XML for printconf
Comment 2 Tim Waugh 2002-05-16 09:19:16 EDT
Does changing that line to: 
/usr/bin/magicfilter-t "$TMP_FILE" $DEBUGSTRING 
help any?
Comment 3 Ed Bailey 2002-05-16 10:43:22 EDT
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... :-)
Comment 4 Ed Bailey 2002-05-16 10:44:53 EDT
Created attachment 57586 [details]
lpq.0 output with original mf_wrapper file (queue empty at job start)
Comment 5 Ed Bailey 2002-05-16 10:45:41 EDT
Created attachment 57587 [details]
lpq.0 output with modified mf_wrapper (queue empty at job start)
Comment 6 Tim Waugh 2002-05-16 10:58:07 EDT
'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 
Comment 7 Ed Bailey 2002-05-16 11:06:44 EDT
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... :-\
Comment 8 Tim Waugh 2002-05-16 11:12:03 EDT
echo "This is a test" | lpr 
doesn't work?  What type of things have you tried printing via lpr?
Comment 9 Ed Bailey 2002-05-16 12:22:16 EDT
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...
Comment 10 Tim Waugh 2002-05-23 05:45:29 EDT
Did it work on 7.2+updates?
Comment 11 Ed Bailey 2002-05-23 07:23:12 EDT
Yes, no problems at all until I installed 7.3...
Comment 12 Tim Waugh 2002-05-24 05:14:15 EDT
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. 
Comment 13 Need Real Name 2002-05-30 11:06:18 EDT
 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
Comment 14 Need Real Name 2002-05-30 11:17:14 EDT
 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: 
Comment 15 Tim Waugh 2002-05-30 11:20:25 EDT
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.
Comment 16 Tim Waugh 2002-06-17 12:09:33 EDT
Comment 17 Bill Terry 2002-06-24 16:10:09 EDT
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.
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
Comment 18 Tim Waugh 2002-06-24 16:27:16 EDT
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. 
Comment 19 Bill Terry 2002-06-26 16:39:22 EDT
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.
Comment 20 Tim Waugh 2002-06-27 06:57:18 EDT
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  
Comment 21 Tim Waugh 2002-06-27 07:02:52 EDT
(There's no chance that it's a firewall problem is there?)
Comment 22 Tim Waugh 2002-07-08 11:56:57 EDT
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.
Comment 23 Ed Bailey 2002-07-09 11:37:39 EDT
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... :-)

Comment 24 Tim Waugh 2002-07-10 06:14:23 EDT
(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?
Comment 25 Tim Waugh 2003-01-07 05:52:24 EST
Using devfs, by any chance?
Comment 26 Tim Waugh 2005-09-16 12:37:42 EDT
No feedback.

Note You need to log in before you can comment on or make changes to this bug.