Bug 48024 - LPRng RPM should create /var/spool/lpd if it doesn't exist
Summary: LPRng RPM should create /var/spool/lpd if it doesn't exist
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: LPRng
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-09 14:21 UTC by Warren Young
Modified: 2007-04-18 16:34 UTC (History)
0 users

Clone Of:
Last Closed: 2001-07-09 14:22:01 UTC

Attachments (Terms of Use)

Description Warren Young 2001-07-09 14:21:58 UTC
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:

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

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-09 02:30:15 UTC
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.