Bug 48024 - LPRng RPM should create /var/spool/lpd if it doesn't exist
LPRng RPM should create /var/spool/lpd if it doesn't exist
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: LPRng (Show other bugs)
7.1
All Linux
medium Severity low
: ---
: ---
Assigned To: Crutcher Dunnavant
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-09 10:21 EDT by Warren Young
Modified: 2007-04-18 12:34 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-09 10:22:01 EDT
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 Warren Young 2001-07-09 10:21:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
If /var/spool/lpd is missing, printconf-backend will scream and die when
you ask it to rebuild the /etc/printcap files.  The symptom could be fixed
by making printconf-backend smarter, but /var/spool/lpd needs to exist,
always, when the local system uses LPRng.  Therefore, I think it's LPRng's
responsibility to make sure that directory exists.

How reproducible:
Always

Steps to Reproduce:
# rm -rf /var/spool/lpd

Then run printconf-gui from a terminal window and hit the Apply button. 
You'll see a Python backtrace in the terminal.  This leads you to the code
where it's trying to walk the tree underneath /var/spool/lpd looking for
"volatile" directories.

Additional info:

I came across this problem while trying to fix a printing problem.  The
machine had been upgraded from RH6.2 to 7.1 -- printing worked before the
upgrade, and didn't afterward.  I decided to remove everything I could find
related to printing: /var/spool/lpd/*, /etc/printcap*, the LPRng and
printconf RPMs, etc.  I then reinstalled the RPMs, assuming they'd bring
the print sybsystem back to a working state, so I could re-create my
printer.

Strictly speaking, I caused this problem, but a core directory like
/var/spool/lpd should have an RPM package that owns it and is responsible
for re-creating it when someone blows it away.

(For what it's worth, the _real_ problem turned out to be a conflict with
the old LPT1 port, 0x3BC -- I think the vesafb feature interferes with it. 
I changed the port in the BIOS to 0x378 and it began working.)
Comment 1 Crutcher Dunnavant 2001-08-08 22:30:15 EDT
this is part of the filesystem rpm. It is ALWAYS there. Having rpms add bits
they need that are part of this base leads to madness.

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