I have installed Fedora Core 4 on a new machine and am generally very
pleased. However, I am having trouble with printing to an SMB printer.
The print server is an OS/2 Warp Server for e-Business machine
functioning as the primary domain controller for a small network. This
server supports OS/2, Windows and Linux clients and has worked
flawlessly for several years.
>From the Fedora machine, I can see all of the shares on the server. If
I issue smbclient -L, the result is:
[root@fedora mok]# smbclient -L coffmx94 -I 192.168.0.18 -U mok%password
Sharename Type Comment
--------- ---- -------
IPC$ IPC Remote IPC
ADMIN$ Disk Remote Admin
A$ Disk Drive Share for Admin Use
B$ Disk Drive Share for Admin Use
C$ Disk Drive Share for Admin Use
D$ Disk Drive Share for Admin Use
NETLOGON Disk Domain controller share
IBMLAN$ Disk OS/2 LAN Server root
SERVERC Disk C Driver of Domain Server
PRINTER Printer Epson Color Stylus 740
GHOSTPRI Printer PostScript interface to Epson
NECPRINT Printer NEC SilentWriter 890
Server Comment
--------- -------
COFFMX94
Workgroup Master
--------- -------
I created network printers using CUPS on the Fedora machine
corresponding to the printers listed above. I can print test pages
using the graphical print configuration tool, however when I print from
an application, the printing fails. I set the CUPS debugging level to
debug2, but there was not much information of interest in the log files.
I quote the parts which seem relevant to me below:
These are the parameters from the beginning of the job.
D [...] [Job 21]
D [ ] [Job 21] Parameter Summary
D [...] [Job 21] -----------------
D [...] [Job 21]
D [...] [Job 21] Spooler: cups
D [...] [Job 21] Printer: NECPrinter
D [...] [Job 21] PPD file: /etc/cups/ppd/NECPrinter.ppd
D [...] [Job 21] Printer model: NEC SilentWriter LC 890
Foomatic/Postscript (recommended)
D [...] [Job 21] Job title:
D [...] [Job 21] File(s) to be printed:
D [...] [Job 21] <STDIN>
This is where the job fails.
D [...] [Job 21] Starting renderer
D [...] [Job 21] JCL: <job data>
D [...] [Job 21]
D [...] [Job 21] renderer PID kid4=19860
D [...] [Job 21] renderer command: level=0; /usr/bin/printf "%%!\n%%%% %
%%%\n<</HWResolution[300 300]>>setpagedevice\n<</Duplex
false>>setpagedevice\n"; if [ $level -gt 0 ]; then if [ $level -lt 99 ];
then level=" -dLanguageLevel=$level"; else level=""; fi; gs -q
-dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=pswrite$level -sOutputFile=-
-; else cat; fi
E [...] [Job 21] Error writing spool: SUCCESS - 0
D [...] [Job 21]
D [...] [Job 21] Closing renderer
D [...] [Job 21] KID3 exited with status 0
D [...] [Job 21] Process dying with "error closing *main::STDOUT", exit
stat: 9
D [...] [Job 21] error: Broken pipe (32)
D [...] [Job 21] error closing *main::STDOUT
D [...] [Job 21] KID4 exited with status 9
D [...] [Job 21] Renderer exit stat: 9
D [...] [Job 21] KID3 finished
D [...] [Job 21] Renderer process finished
D [...] [Job 21] Killing process 19859 (KID3)
D [...] [Job 21] Process dying with "Error closing renderer", exit stat:
9
D [...] [Job 21] error: Bad file descriptor (9)
D [...] [Job 21] Error closing renderer
E [...] PID 19855 stopped with status 9!
D [...] UpdateJob: job 21, file 0 is complete.
The first error message above seems to come from the smbspool command
used as the backend.
If I issue smbspool by itself, I receive the same error message.
[root@fedora mok]# smbspool smb://MOK:password@coffmx94/PRINTER 1 user
title 1 '' /usr/share/gimp-print/doc/gimpprint.ps
ERROR: Error writing spool: SUCCESS - 0
(I chose the gimpprint.ps file above just because it is large.)
When I check the spool directory on the server machine, there are files
created, and they look like the beginnings of valid postscript files.
However, each has the same file size: 73728 bytes. The files end
suddenly in 'midstream'. The size is, of course, a small fraction of the
correct file size and tantalizingly is equal to 9*8192.
I have never had trouble printing to this server before using smb but at
that time I was using RedHat 6.2. I must be doing something wrong but I
am now at a loss. Has anyone seen a similar problem? Does anyone have
any ideas?
Thanks!
Dan Coffman
