Cannot print after CUPS update

trevor4706 · 01-23-2008, 02:05 PM

I am running Fedora 8 in a dual-boot installation with XP. Last Saturday I downloaded some updates, which included some updates to CUPS. Following the update I can no longer print from my HP Photosmart 4180. Printer works fine from XP. When I try to print nothing happens. The printer dialog shows "processing" ad infinitum. In the CUPS admin tool the printer has the statement "Open device failed, will retry in 30 sec...".

The command "lsusb" shows the printer. I've un-installed and re-installed the printer with no change. I have a feeling it's a permissions issue, but am not really sure where to start. Any suggestions would be greatly appreciated.

Lenard · 01-24-2008, 07:15 AM

Try the following as root or equivalent;

Stop the service: service cups stop
Clean out the /var/spool/cups directory: rm -r /var/spool/cups
Re-start the service: service cups start

trevor4706 · 01-24-2008, 06:50 PM

Lenard

I did what you suggested, and was unable to re-start cups. When I try to do so, I get the following error message:

cups failed. The error was: Stopping cups: [FAILED]

Starting cups: cupsd: Child exited with status 1!
[FAILED]

And this message from syslog:

Message from syslogd@localhost at Jan 24 19:47:32 ...
cupsd: Unable to read configuration file '/etc/cups/cupsd.conf' - exiting!

The file /etc/cups/cupsd.conf exists, so I'm not exactly sure why cupsd cannot read it.

gilead · 01-24-2008, 07:07 PM

Do you have a backup copy of the .conf file that you can try? If not, can you post the contents here as well as any messages from /var/log/cups?

trevor4706 · 01-24-2008, 07:39 PM

Steve

I've been looking at the /etc/cups/cupsd.conf file. Almost every line is commented out with a "#". I have three other cupsd.conf-type files in the /etc/cups directory: cupsd.conf.default, cupsd.conf.rpmnew, and cupsd.conf.save. The first two of these appear identical, while the third looks like a sample conf file.

If I were to remove cups and then re-install, would a new cupsd.conf file be produced?

gilead · 01-24-2008, 08:30 PM

IIRC, cupsd.conf.default is a copy of the one that is originally installed by the CUPS package. cupsd.conf.rpmnew was added when the package was updated and cupsd.conf.save should be a backup of your original file. What is the output from the following please:

Code:

diff -us /etc/cups/cupsd.conf{,.save}

That should show whether there were changes made when the package was updated.

trevor4706 · 01-24-2008, 10:16 PM

The output indicate that there were changes made. Here it is:

[root@localhost ~]# diff -us /etc/cups/cupsd.conf{,.save}
--- /etc/cups/cupsd.conf 2008-01-24 20:46:07.000000000 -0500
+++ /etc/cups/cupsd.conf.save 2005-10-29 15:14:40.000000000 -0400
@@ -1,39 +1,851 @@
LogFilePerm 0600
MaxLogSize 2000000000
LogLevel info
Printcap /etc/printcap
Port 631
<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
</Location>
<Location /admin>
<Location /admin>
AuthType Basic
AuthClass System
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
</Location>
-<Location /printers/Epson>
-Order Deny,Allow
-Deny From All
-Allow From 127.0.0.1
-AuthType None
-Allow from All
-</Location>
-Browsing On
-BrowseProtocols cups
-BrowseOrder Deny,Allow
-BrowseAllow from @LOCAL
-BrowseAddress 255.255.255.255
-Listen *:631

gilead · 01-25-2008, 12:31 AM

I haven't used all of those browsing options listed at the bottom of the output and unless the Location /printers/Epson section is a duplicate of another part of the file, it looks OK too.

To answer your earlier question, uninstalling and re-installing should remove all of the files (you can remove /etc/cups manually regardless) so you can then add it as a new printer. It's not the ideal solution but it may well be quicker than waiting for somebody who recognises the exact problem.

trevor4706 · 01-25-2008, 12:34 PM

I un-installed and reinstalled CUPS, but still got the "open device failed" message. Then I re-traced my steps and realized that when I tried an earlier fix I'd found on a forum, instead of using the command "chmod 700 /usr/lib/cups/backend/hp" I had used "chmod 777/usr/lib/cups/backend/hp". I guess I thought that if giving root rwx permissions was good, giving everyone the same permissions was better. Not so. I ran the command "chmod 700/usr/lib/cups/backend/hp" and tried to print. Bingo, eveything worked as it had before the CUPS update. Go figure.

Thanks for your help, gilead.

jschiwal · 01-25-2008, 12:54 PM

Check if the problem is with your selinux settings. Cups may be denied access to its own config file.

zek · 03-12-2008, 03:25 AM

Quote:

Originally Posted by Lenard

Try the following as root or equivalent;

Stop the service: service cups stop
Clean out the /var/spool/cups directory: rm -r /var/spool/cups
Re-start the service: service cups start

Ok, so I did that and now I get the same error message:

Code:

Message from syslogd@localhost at Mar 12 09:18:43 ...
 cupsd: Unable to read configuration file '/etc/cups/cupsd.conf' - exiting!

As well as a SELinux message stating that

Code:

SELinux is preventing cupsd (cupsd_t) "write" to ./spool (var_spool_t).

It's kind enough to suggest that

Code:

SELinux is preventing cupsd (cupsd_t) "write" to ./spool (var_spool_t). 
The SELinux type var_spool_t, is a generic type for all files in the directory
 and very few processes (SELinux Domains) are allowed to write to this SELinux type.
 This type of denial usual indicates a mislabeled file. By default a file created 
in a directory has the gets the context of the parent directory, but SELinux policy 
has rules about the creation of directories, that say if a process running in one 
SELinux Domain (D1) creates a file in a directory with a particular SELinux 
File Context (F1) the file gets a different File Context (F2). 
The policy usually allows the SELinux Domain (D1) the ability to write, unlink, and 
append on (F2). But if for some reason a file (./spool) was created with the wrong context, 
this domain will be denied. The usual solution to this problem is to reset the file 
context on the target file, restorecon -v './spool'. 
If the file context does not change from var_spool_t, then this is probably a bug in policy.

However, I can't imagine any way to implement this solution - where and what is the file './spool'?