From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
Nothing would print on my hpdeskjet 920c, after a fresh install of rh9.0
It worked fine in 8.0.
If I added LogLevel debug2 to /etc/cups/cupsd.conf, I could see the following
error in /var/log/cups/error_log:
D [05/May/2003:00:19:16 -0700] [Job 12] Couldn't exec foomatic-gswrapper -q
-dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ijs -sIjsServer=hpijs
-sDeviceManufacturer="HEWLETT-PACKARD" -sDeviceModel="DESKJET 920"
-dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dDuplex=false -r300
-dIjsUseOutputFD -sOutputFile=- - at /usr/lib/cups/filter/cupsomatic line 1097.
After *much* debugging, it turns out that foomatic-gswrapper was working, but gs
was failing silently. An strace of gs showed that it was getting access denied
messages while trying to read its fonts.
chmod -R a+rX /usr/share/fonts
Maybe put something like this into /etc/rc.d/init.d/xfs ?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.chmod go-rx /usr/share/fonts
4.chmod -R go+rX /usr/share/fonts
5.put hair back in
Actual Results: discovered you can't put hair back in
Expected Results: Fabio hair
Fresh install already has the right permissions on that directory.
Fine, yes, I get what you're saying.
Perhaps I didn't clearly state the situation.
When I'm root, I always have a umask of 077 when installing rpms. When
diagnosing this printing problem, I examined the /usr/share/fonts directory and
all subdirectories, and I found that some files and some directories were not
readable by group or others. Specifically, the directory containing the font
files for ghostscript could not be read by ghostscript when it was called from
the print spooler.
It could be that an rpm package rebuilt the font directories with the wrong
permissions, possibly obeying the umask when it shouldn't have.
My primary reason for sending in this bug report is so that other people who
have cryptic failures of their printing subsystem might find a solution in this
My secondary reason was that I was hoping that someone might add some code to
the file /etc/rc.d/init.d/xfs that said 'chmod -R a+rX /usr/share/fonts', so
that nobody would have this sort of mysterious failure. Since that file is
already running mkfontdir on boot if new fonts have been added, I figured that
would be as good a place as any to put the fix.
Alternatively, if chmod -R is too intrusive/may trample permissions that people
are setting up on purpose, then maybe just report that some files are not
readable by all, and let the administrator deal with it.
Or make ghostscript report that it can't read its fonts, and pass that error
back up the tree so that people like me don't have to strace the printing
subsystem in order to figure out it's a minor permissions problem, and not a bug
deep in the heart of the printing subsystem.
I mean, really, I'm an experienced Linux sysadmin, and it took me 2 hours and 37
seconds to debug this problem. I *know* that I haven't done anything out of the
ordinary during the installation of this system. If it takes me 2 hours, then
it's going to make a newbie give up. And tell his/her friends that Linux sucks.
I don't think anybody here wants that, do they?
Aha, some package should own /usr/share/fonts, but none does.
Maybe fontconfig should own /usr/share/fonts?
*** This bug has been marked as a duplicate of 110956 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.