lp : drivers loaded but no devices found - [re-opened]

Problems and successes with specific brands/models of printers
Message
Author
User avatar
Patriot
Posts: 733
Joined: Thu 15 Jan 2009, 19:04

#21 Post by Patriot »

Hmmm .....
xav795 wrote: ........
rm -fr /var/spool/cups
/etc/init.d/cups restart

then i can print something without problem until my next reboot.
Each time a boot, i can't start printing someting without executing these two lines.
On your next reboot, before doing the two lines above, please do this in a terminal :

ls -la /var/spool
ls -la /var/spool/cups

and do it again after executing the rm -fr & cups restart ... We'll be able to compare the difference, if any .....


Rgds

xav795
Posts: 26
Joined: Sat 18 Jul 2009, 11:03
Location: France, Paris

#22 Post by xav795 »

Hi,

There is something strange : Each time i reboot, i am getting files in /var/spool/cups, that i must delete, else, my future print job won't be done, because of the permission denied message.
(One thing i do at each reboot is to force filechecking with the option in syslinux.cfg : pfix=fsck,copy.)
Here are the steps :

0. I am starting with a fresh /var/spool/cups that is empty.

1. First i reboot
Executing the ls, i get :
# ls -la /var/spool
total 8
drwxr-xr-x 5 root root 4096 2009-11-09 14:05 .
drwxr-xr-x 24 root root 100 2009-11-02 20:17 ..
drwxr-xr-x 3 root root 25 2005-12-05 23:56 cron
drwx--x--- 4 root nobody 4096 2009-11-09 23:32 cups

# ls -la /var/spool/cups
total 228
drwx--x--- 4 root nobody 4096 2009-11-09 23:32 .
drwxr-xr-x 5 root root 4096 2009-11-09 14:05 ..
-rw------- 1 root nobody 729 2009-11-02 16:30 c00005
-rw------- 1 root nobody 910 2009-11-03 15:25 c00006
-rw------- 1 root nobody 746 2009-11-06 10:35 c00007
-rw------- 1 root nobody 746 2009-11-06 10:43 c00008
-rw------- 1 root nobody 872 2009-11-09 09:54 c00011
-rw------- 1 root nobody 746 2009-11-09 14:05 c00013
-rw------- 1 root nobody 746 2009-11-09 14:13 c00014
-rw-r----- 1 root nobody 185304 2009-11-03 15:25 d00006-001
drwxrwx--T 2 root nobody 4096 2009-11-09 14:13 tmp

2. I delete all and restart cups with
rm -fr /var/spool/cups
/etc/init.d/cups restart

3. Executing the ls again, i get :
# # ls -la /var/spool
total 0
drwxr-xr-x 6 root root 60 2009-11-10 09:36 .
drwxr-xr-x 26 root root 140 2009-11-02 20:17 ..
drwxr-xr-x 3 root root 25 2005-12-05 23:56 cron
drwx--x--- 3 root nobody 80 2009-11-10 09:36 cups
# ls -la /var/spool/cups
total 0
drwx--x--- 3 root nobody 80 2009-11-10 09:36 .
drwxr-xr-x 6 root root 60 2009-11-10 09:36 ..
drwxrwx--T 2 root nobody 40 2009-11-10 09:36 tmp

Rgds,

samwathegreat
Posts: 7
Joined: Mon 08 Feb 2010, 03:10

Identical problem

#23 Post by samwathegreat »

I'm having an identical problem to xav795's.

I'm using the cups 1.3.11 pet, and everything works fine until I reboot. Then printing no longer works, and I begin getting permission denied errors. The only solution is to delete the /var/spool/cups directory, and restart cups.

I've tried a complete reinstall and the problem persists. I am not able to find any cause, as the permissions show up exactly the same before I delete the /var/spool/cups directory as it does when I restart cups and it gets re-created. How strange? This isn't a huge issue, as I seldom re-boot, however, if there is no logical explanation to why this is happening, could someone please help me write a script that will automaticly delete the /var/spool/cups directory BEFORE cups gets started by /etc/init.d/cups on each reboot?

I believe this could be my simplest solution, and since I'm not concerned with keeping a log of print history I don't see any potential problems with this.

Is anyone else having this problem?? It just doesn't make sense.

Thank You

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#24 Post by jpeps »

If you're seeing the extra files like xav795, it's most likely some file corruption issue (on my system, they're only in tmp)

edit: or bug?

samwathegreat
Posts: 7
Joined: Mon 08 Feb 2010, 03:10

Workaround found

#25 Post by samwathegreat »

Thanks for the reply jpeps

It would seem to me that this problem is un-related to corrupted file system, since both xav795 and myself have completely started from scracth (and a new puppy). I have completely re-formatted my drive and started over, even though I had no reason to believe that my filesystem was corrupted. First thing I did afterwards was install cups 1.3.11 pet and proceed with trying to get cups to work.

Nonetheless, the problem has persisted for both both of us, continuing to get the dreaded "Unable to open file "/var/spool/cups/xxx" - Permission denied" error, and no print output.

Since removing the /var/spool/cups directory & subsequently restarting cups makes everything work fine until reboot (and since there doesn't seem to be a solution available), I've come up with the following work-around:

#####EDIT! 2-8-10 DO NOT USE THIS SCRIPT! See my post below#####

Create a new file in /etc/init.d lets call it "fixcups"
Copy this code into the new file:
#!/bin/sh
# Fixcups
# Script to remove cups spool directory on shutdown
if [ "$1" = "start" ]
then
echo -n "doing nothing"
exit
fi

if [ "$1" = "stop" ]
then
echo -n "removing cups spool directory"
rm -fr /var/spool/cups
exit
fi

echo "Useage: `basename "$0"` [start|stop]"



Since puppy runs everything in init.d with "start" when the computer boots, you will see that this script does absolutely nothing at startup.

At shutdown, however, puppy runs everything in init.d with the directive "stop", so the script removes the cups spool directory at shutdown. How convenient! At the next boot, cups will start, and immediately re-build the /var/spool/cups directory, and printing will work without permission denied errors.

Why not create a startup script that removes the /var/cups/spool directory and also restarts cups at boot? Because I'm not sure what order the files in init.d get executed....it wouldn't be good to "restart cups" before cups even starts, right? With my solution, there -shouldn't- be any side-effects, since we're just removing a directory that will get rebuilt at the next boot.

I hope this helps someone else out.

Thanks everyone for the help.
Last edited by samwathegreat on Mon 08 Feb 2010, 19:31, edited 2 times in total.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#26 Post by jpeps »

Kind of weird it's saving jobs anyway, if /etc/cups/cupsd.conf has "PreserveJobHistory Off". After deleting the few jobs in tmp on my system, it didn't add any new ones after printing some test jobs from Geany.

xav795
Posts: 26
Joined: Sat 18 Jul 2009, 11:03
Location: France, Paris

#27 Post by xav795 »

Hi jpeps,

I just tried these options in /etc/cups/cupsd.conf,
PreserveJobHistory Off
PreserveJobFiles Off

I then deleted the files within this folder
rm -fr /var/spool/cups
and restarted cups
/etc/init.d/cups restart

Printing a document then work, but like each time, even without the option in cupsd.conf

So i restarted toutoulinux , (french 4.1.2 pupplet.)

The /var/spool/cups directory is still containing files, it's seems to be the history, and i can't print without doing a clean of these old files.

So i am still using these commands , like samwathegreat, when i want to print for the first time after booting :
rm -fr /var/spool/cups
/etc/init.d/cups restart
It works well but this is not clean because files in this folder are growing.
There is a purge somewhere that does not work.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#28 Post by jpeps »

Also setting "AutoPurgeJobs Yes" and "MaxJobs 1" and then restarting cups doesn't work either?

samwathegreat
Posts: 7
Joined: Mon 08 Feb 2010, 03:10

NEW SOLUTION

#29 Post by samwathegreat »

Ok so the shutdown script did have some unwanted side effects....caused a problem loading cups at the next boot.

Here is my FINAL solution, this one is tested confirmed working great. Simply edit the /etc/init.d/cups file:

Find the section of the script for start:

case $1 in
start | restart | reload)
if $IS_ON cups; then
if test "$pid" != ""; then
kill -HUP $pid
else
rm -fr /var/spool/cups
prefix=/
exec_prefix=/usr
/usr/sbin/cupsd
if test $? != 0; then
$ECHO_FAIL
$ECHO "cups: unable to $1 scheduler."
exit 1
fi
fi
$ECHO_OK
$ECHO "cups: ${1}ed scheduler."


and add the line

rm -fr /var/spool/cups

right before prefix=/


This solution removes the spool directory RIGHT before cups gets started. I've checked the logs, and there are no side effects, and printing works right away.

Good Luck!

samwathegreat
Posts: 7
Joined: Mon 08 Feb 2010, 03:10

Update

#30 Post by samwathegreat »

Update:

The modified startup script continues to work flawlessly :)

For anyone who is interested in finding out why this has to be done, I've found something interesting:

If the modified startup script is not used, at the next boot, we will receive the dreaded "Unable to open file "/var/spool/cups/xxx" - Permission denied" error - the problem xav and I have been experiencing.

What i've noticed is that when it doesn't work, the job will appear in the "jobs" section of cups under the user "anonyomous", or "nobody" or my windows username if I'm tryint to print through samba. Nothing gets printed, and cups shows status as stopped with the permission denied error. Also, -everything- that you try to print shows up in the status and does not go away.

However!, after running:

rm -fr /var/spool/cups
/etc/init.d/cups restart

1) everything in jobs disappears (naturally...we just deleted the spool directory)
2) anything that I print actually DOES print
3) EVERYTHING that I print (whether through lpn, cups test page, or windows samba client) shows up in the cups "jobs" page showing user "root" None of them show "nobody" or "anonoymous"!

So it seems that after a reboot, cups writes anything that gets printed into the spool directory with that user's username (e.g. nobody, anonymous), BUT once you delete the spool directory & restart cups (and cups re-builds the spool directory and "repairs permissions") any printed files get written to the spool directory as user "root"

This seems to be the key - it looks to me like at each reboot, cups writes print jobs to the spool directory as "nobody, etc.", and subsequently, the necessary filters aren't able to read the file because of permissions mismatch. After executing our "fix", everything gets written as root, so the filters are able to process the print jobs without errors.

I've also noticed that this bug doesn't seem to affect post-script printers because there is no filtering to be done.

It also doesn't seem to affect windows samba clients, printing to a non-postscript printer when you use the proper windows driver for your printer, and set it to "print directly to printer" (raw). I'm guessing that once again, this is because the file doesn't need to pass through any filters, cups simply sends the raw data to the printer, and it prints fine.

It only seems to affect non-postscript printers when printing anything from a linux box, including the cups "print test page" (because it has to pass through the appropriate filters).

If anyone is interested, the printer I'm using is a canon MP-240, and I'm using "Patriot"s Canon MP-240 Puppy pet package (from 3.00 source) from http://www.murga-linux.com/puppy/viewtopic.php?t=47444

After viewing the cups error log in debug mode, I see that the printing process gets stopped when cups tries to pass the job through the "pstops" filter - the log shows "Unable to open file "/var/spool/cups/xxx" - Permission denied" THE SAME error that we see on the cups "printer" page.

So it has something to do with how cups writes the print jobs to /var/spool/cups & who "owns" the file. Seems that if it's not root, the filters can't read it.

Nonetheless, the modified startup script fixes the problem so I'm happy (and I can print!!)
Last edited by samwathegreat on Mon 08 Feb 2010, 19:40, edited 1 time in total.

samwathegreat
Posts: 7
Joined: Mon 08 Feb 2010, 03:10

#31 Post by samwathegreat »

Also, I want to point out that with the fix from my above post, I am NOT having xav's problem with the spool directory still containing files. Everything gets removed - I've also noticed that NOW (after using fix), cups automaticly deletes the processed/completed jobs after a few minutes. I can look in /var/spool/cups OR the Cups jobs page (show completed jobs), and they both show empty. Before, everything just piled up in there, so seems to have fixed this problem as well.

User avatar
Patriot
Posts: 733
Joined: Thu 15 Jan 2009, 19:04

#32 Post by Patriot »

Hmmm .....

This /var/spool/cups folder issue reminds me of one old cups-1.1.23 problem I had a long time ago ... I moved it to tmp to make it work ...

I guess its time to start poking into cups again soon ... Ok, guys, can't make any promises when it'll happen but I'll look into the spool folder issue again later and see what its about ...


Rgds

xav795
Posts: 26
Joined: Sat 18 Jul 2009, 11:03
Location: France, Paris

#33 Post by xav795 »

jpeps wrote:Also setting "AutoPurgeJobs Yes" and "MaxJobs 1" and then restarting cups doesn't work either?
jpeps,

I then have only one job in the folder, but it does not print anymore, i still have the permission denied error message.

Rgds

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#34 Post by jpeps »

Did you change it to root root? (eg, chown the cups directory)

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#35 Post by jpeps »

jpeps wrote:Did you change it to root root? (eg, chown /cups/*)

xav795
Posts: 26
Joined: Sat 18 Jul 2009, 11:03
Location: France, Paris

#36 Post by xav795 »

jpeps,

After having changed it with:
chown root:root cups
I then restart cups, and the old owner went back.
I don't know if having "nobody" in group is a problem

Rds

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#37 Post by jpeps »

xav795 wrote:jpeps,
I don't know if having "nobody" in group is a problem
Rds
According to samwathegreat, that seems to be the issue. Puzzling, though, because he claimed the permission change occurred only after a reboot, not after a cups restart. I believe the cups directory (and its files) should be root:root

Code: Select all

drwx--x--- 4 root root 4096 2010-02-08 15:56 /var/spool/cups/

samwathegreat
Posts: 7
Joined: Mon 08 Feb 2010, 03:10

#38 Post by samwathegreat »

I don't see a difference in the permissions of the /var/spool/cups directory when cups gives the error vs. when everything is working normally.

They are identical in both instances (root:root), so it seems that when cups is restarted (or just started) with the /var/spool/cups directory missing, cups subsequently re-creates them and "repairs permissions" (I've seen this in my debug cups log) that it also changes something else? Seems to me like it also changes the way cups writes data to the /var/spool/cups.

Also, I've noticed that when I print from my other computer running puppy (through IPP), the job shows up under "anonymous" - but anything printed locally or via samba shows up as "root", so it's not always root. (but still works with workaround)

I'm still quite puzzled myself. However, the fix I referenced before (modify /etc/init.d/cups file) is still going strong. Puppy always prints, even after several reboots.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#39 Post by rcrsn51 »

@samwathegreat

May I make a few comments about your situation? First, the persistent c0000x files are a "feature" of CUPS. There is some maximum default number of these files that are retained, at which point CUPS will start deleting them. However, I was able to make them auto-delete by using these lines in cupsd.conf just below the LogLevel line:

Code: Select all

PreserveJobHistory No
PreserveJobFiles No
There is nothing wrong with the root:nobody ownership of CUPS files. That's how CUPS works normally. IIRC, it has something to do with security issues and CUPS 1.3.x not wanting to process print jobs as the full privileged root:root user .

That said, I set up a fresh copy of 4.3.1 and installed CUPS 1.3.11 and your Canon MP-240 driver. (Since I don't own your printer, I assigned it to a disconnected port like LPT1.) In all cases, print jobs were processed correctly and there were no errors reported from the pstops filter.

FWIW, I have two other printers working fine in this setup. I also have CUPS 1.3.11 working correctly in another Linux with non-root ownership of print jobs.

I am certainly not disputing your own experience, but I don't know what would be causing your problem. Are you installing any additional printing functionality, like the Samba server? Or maybe the Canon backend is causing the problem. It would be interesting to know what happens if you install a different printer on your system.

[Edit] Are you using the cupsd.conf file that comes with Patriot's package or an older / modified version? It looks like you have configured CUPS for network printer sharing. Maybe that's involved.

Are you, like xav795, using a version of Puppy 4.1.2?

What install method - full, frugal, flash drive?

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#40 Post by rcrsn51 »

What install method - full, frugal, flash drive?
I can confirm that if you have Puppy and CUPS 1.3.11 installed on a flash drive, you will get the Permission Denied error described above.

I suspect that the problem is caused by the special layered filesystem used on a flash drive. It looks like CUPS always starts off using the original /var/spool/cups folder in the sfs filesystem, which has root:root ownership. Hence the permission problem. Once you white out that folder and let CUPS replace it with the correct version, you can print. But on the next reboot, CUPS somehow reverts back to the original even though you see the correct one in your view of the filesystem.

In retrospect, I believe that there have been other episodes of strange CUPS behaviour involving flash drives.

Post Reply