Bug 22617 - RedHat Printer Tool has problem with spooler in 7.0
RedHat Printer Tool has problem with spooler in 7.0
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: printtool (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-12-20 16:40 EST by Bruno Melloni
Modified: 2007-04-18 12:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-05 09:30:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruno Melloni 2000-12-20 16:40:25 EST
After a normal install of RedHat 7.0, I used the Printer Tool to access my
printer (using the Local Printer option), as I have done in all previous
RedHat versions.

Then I used the Tests menu option to confirm everything works.  No problem
with "Print ASCII directly to port", but both "Print ASCII text page" and
"Print Postcript text page" fail with the following error:

----
Error printing test page to queue lp

Error reason: Status Information:
  sending job 'root@planck+642' to lp@localhost
  connecting to 'localhost', attempt 1
  connected to 'localhost'
  requesting printer lp@localhost
  job 'root@planck+642' transfer to lp@localhost failed
    error 'NONZERO RFC1179 ERROR CODE FROM SERVER' with ack 'ACK_FAIL'
    sending str '^Blp' to lp@localhost
  error msg: 'spool queue for 'lp' does not exist on server planck'
  error msg: '    non-existent printer or you need to run 'checkpc -f' '
-----

The printer of course exists (as it prints fine with the "directly to port"
option).

Running "checkpc -f" returns "Warning - 'if' filter
'/var/spool/lpd/lp/filter' does not have execute perms" but fails to
correct the problem (which checkpc is supposed to do).  

'filter' is a symbolic link to
/usr/lib/rhs/rhs-printfilters//master-filter.  I tried replacing it with
one to /usr/lib/rhs/rhs-printfilters/master-filter, with no effect.  I
added the execute permission to "master-filter", with no effect other than
checkpc not returning the error - but still failing the tests with the
print tool.  I also tried changing the symbolic link ownership and group to
lp, also to no effect.

Setting up a printer with previous versions was a no-brainer.  The print
tool used to work flawlessly.

bruno
Comment 1 jbednar 2000-12-20 20:16:38 EST
I'm having almost exactly the same problem.  

I did a brand-new install of 7.0, but unfortunately did not try to
define a new printer before installing ghostscript 6.01.  I then used
printtool to define a new printer, which works fine when text is
printed directly to the port.  However, both ASCII and PostScript test
pages fail with lpr messages like the above, as does lpr directly (see
attached transcript). checkpc initially found some permissions
problems, but it fixed them, to no avail.  I don't really suspect gs
6.01, since I get the same behavior for ASCII and PostScript input
files and no matter what printer model I select in printtool, even a
generic PostScript printer.

LPRng unfortunately doesn't say where it is trying to find the spool
directory; its man page says /var/spool/printer*, which doesn't match
what printtool generates, but I didn't notice any change from copying
/var/spool/lpd/glossy to /var/spool/glossy ...

doozy:~> checkpc -f
Warning - owner/group of '/var/spool/lpd/glossy/control.glossy' are 0/7, not 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/control.glossy' to 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/control.glossy' to 4/7
Warning - owner/group of '/var/spool/lpd/glossy/status.glossy' are 0/7, not 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/status.glossy' to 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/status.glossy' to 4/7
Warning - owner/group of '/var/spool/lpd/glossy/status' are 0/7, not 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/status' to 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/status' to 4/7
Warning - owner/group of '/var/spool/lpd/glossy/log' are 0/7, not 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/log' to 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/log' to 4/7
Warning - owner/group of '/var/spool/lpd/glossy/acct' are 0/7, not 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/acct' to 4/7
Warning -   changing ownership '/var/spool/lpd/glossy/acct' to 4/7
doozy:~> checkpc -f
doozy:~> lpr -Pglossy file.txt 
Status Information:
 sending job 'root@doozy+895' to glossy@localhost
 connecting to 'localhost', attempt 1
 connected to 'localhost'
 requesting printer glossy@localhost
 job 'root@doozy+895' transfer to glossy@localhost failed
  error 'NONZERO RFC1179 ERROR CODE FROM SERVER' with ack 'ACK_FAIL'
  sending str '^Bglossy' to glossy@localhost
 error msg: 'spool queue for 'glossy' does not exist on server
doozy.ots.utexas.edu'
 error msg: '   non-existent printer or you need to run 'checkpc -f''
doozy:~> lpq -Pglossy
Printer: glossy@doozy - ERROR: spool queue for 'glossy' does not exist on server
doozy.ots.utexas.edu
   non-existent printer or you need to run 'checkpc -f'
doozy:~> ls -l /var/spool/lpd
total 1
drwx------    2 lp       lp           1024 Dec 20 19:07 glossy
doozy:~> ls -l /var/spool/lpd/glossy
total 3
-rw-------    1 lp lp              0 Dec 20 17:02 acct
-rw-------    1 lp       lp              0 Dec 20 17:02 control.glossy
lrwxrwxrwx    1 root     root           44 Dec 20 19:07 filter ->
/usr/lib/rhs/rhs-printfilters//master-filter
-rw-------    1 lp       lp            191 Dec 20 19:07 general.cfg
-rw-------    1 lp       lp              0 Dec 20 17:02 log
-rw-------    1 lp       lp            504 Dec 20 19:07 postscript.cfg
-rw-------    1 lp       lp              0 Dec 20 17:02 status
-rw-------    1 lp       lp              0 Dec 20 17:02 status.glossy
-rw-------    1 lp       lp            147 Dec 20 19:07 textonly.cfg
doozy:~>
Comment 2 jbednar 2001-02-01 19:53:30 EST
Well, even though I didn't suspect Ghostscript, it somehow seems to be related
to this problem.  I saw that there was another bug (#18009) that mentions
GS6.01 installing its files in /usr/share/ghostscript/6.01/lib instead of where
printtool expects them, /usr/share/ghostscript/6.01/, so I made symbolic links
from all the files in /usr/share/ghostscript/6.01/lib to
/usr/share/ghostscript/6.01/.  After running checkpc -f and restarting lpd,
everthing magically works.  

Yet just before doing this I defined a text-only printer, and even the ASCII
test page to the text-only printer wouldn't work.  This is pretty silly; there's
no reason why printtool should be depending on ghostscript to define a text-only
printer.  In any case, printtool needs to be updated for gs-6.01, so that it
will check in both $gsver/ and $gsver/lib/.
Comment 3 Crutcher Dunnavant 2001-02-01 20:28:44 EST
Did everyone with this problem restart lpd after they defined their printer?
The test pages don't work if lpd isn't restarted (except for the port test page,
which skips it).

Also, no new development will be undertaken for printtool we have a new system,
printconf. And the issue of compatability with a version of ghostscript which we
cannot legally ship is not high priority at the moment. (Though, yes, it would
be nice)
Comment 4 jbednar 2001-02-01 20:38:18 EST
Yes, I did restart lpd numerous times; restarting it had no effect until I put
in those symlinks for the GS6.01 files.  Of course, if restarting is required,
instead of just useful when things get screwed up, then the configuration tool
should be smart enough to restart it itself when things change, or at least warn
the user to do so.  

If you are going to keep old buggy programs in the distribution for
compatibility reasons, then I would highly recommend that you either (a) fix the
bugs in the old programs, or (b) patch the old programs to recommend that users
switch to the preferred, supported tool (and tell us what it is).  Right now
there are lots of different versions of programs for configuration, etc., and no
clear way to tell which one, if any is correct, up-to-date, and supported.
Comment 5 Tim Waugh 2002-03-06 09:03:12 EST
This is fixed in the current release, isn't it?

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