Red Hat Bugzilla – Bug 90187
Does not work when installed with a umask of 077
Last modified: 2007-04-18 12:53:28 EDT
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 -sIjsParams=Quality:Quality=0,Quality:ColorMode=2,Quality:MediaType=0,Quality:PenSet=2 -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. Solution: 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): foomatic-2.0.2-15, cups-1.1.18-4 How reproducible: Always Steps to Reproduce: 1.chmod go-rx /usr/share/fonts 2.lpr /usr/share/ghostscript/7.05/examples/tiger.ps 3.pull hair 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 Additional info:
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 bug database. 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.