Hi, I can not stop print jobs. I'm using SuSE 8.2 and cups: cer@nimrodel:~> lpq -a Rank Owner Job File(s) Total Size active cer 332 (stdin) 26065920 bytes cer@nimrodel:~> lprm 332 cer@nimrodel:~> lpq -a no entries cer@nimrodel:~> So there are no print jobs, but the printer goes on printing. I stop cups: nimrodel:/var/spool/cups # rccups stop Shutting down cupsd done nimrodel:/var/spool/cups # rccups status Checking for cupsd: unused But the printer continues printing. Why!? I see a big file in '/var/spool/cups/tmp' dated now - I forgot to compare its size with the deleted job. I delete it... and printing continues. There is nothing under '/var/spool/lpd' ps afxl|less shows a job: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 0 0 9178 1 15 0 2800 652 schedu S ? 0:03 parallel:/dev/lp0 332 cer (stdin) I guess that the culprit must be "/usr/lib/cups/backend/parallel". Why wasn't it stopped when I stopped cups? Perhaps 'lprm' must be used as root? Finally I stop the printer with "kill -9 9178" (the -9 seems to be needed). Then I can restart cups. Peace! Is this a bug? SuSE 8.1 was also unable to stop print jobs (I asked here about it). Certainly stopping a print job should really stop it. To whom can this be reported? -- Cheers, Carlos Robinson
On Thu, 2003-12-25 at 21:39, Carlos E. R. wrote:
Hi,
I can not stop print jobs.
I'm using SuSE 8.2 and cups:
cer@nimrodel:~> lpq -a Rank Owner Job File(s) Total Size active cer 332 (stdin) 26065920 bytes cer@nimrodel:~> lprm 332 cer@nimrodel:~> lpq -a no entries cer@nimrodel:~>
First most printers have builtin buffers which will not be flushed when you cancel the print job. Second: If you are using cups you should be using lpstat -t (or -o) to list the print jobs. Use cancel <print job#> to cancel the print job and if need be power cycle the printer to flush its buffers. -- Ken Schneider unix user since 1989 linux user since 1994 SuSE user since 1998 (5.2)
The Friday 2003-12-26 at 07:13 -0500, Kenneth Schneider wrote:
First most printers have builtin buffers which will not be flushed when you cancel the print job.
I know. Even so, there is a command to flush it. And in any case, that would account for a few centimiters of graphical output, but not a full dozen of pages full of graphics. Its not so big a memory (canon 4000, inkjet type).
Second:
If you are using cups you should be using lpstat -t (or -o) to list the print jobs.
"lpq -a" lists them all as well. lpstat gives more info, but the print jobs are the same. See: cer@nimrodel:~> lpstat -o lpg-334 cer 6406144 Fri 26 Dec 2003 02:15:04 PM CET cer@nimrodel:~> lpq -a Rank Owner Job File(s) Total Size active cer 334 (stdin) 6406144 bytes
Use cancel <print job#> to cancel the print job and if need
As I said yesterady, it doesn't work. Job is cancelled, job quee is empty, but continues printing, nevertheless.
be power cycle the printer to flush its buffers.
Doesn't work. As soon as it comes again on line, it continues printing, but worse: this time it prints garbage in many pages, because the graphics configuration (ESC codes) at the start of a line or job was erased from memory, and the printer can no longer interpret properly what is comming from the computer. You did not read carefully my post: I said that even after cancelling the job and stopping cups, there remains a running task (belonging to root) that continues printing till reboot or manual kill. This program should have been stoped by cups, but it doesn't. -- Cheers, Carlos Robinson
Have you tried using the CUPS Web interface, http://localhost:631 I use it extensively with 8.1 and it will terminate the print jobs, including the backend. Then I either power off the printer or wait for the buffer to finish and then reset the printer. But, I agree that the CLI should work properly as well. May I suggest you verify that the lp tools are the programs supplied with CUPS. I suggest it because they have their own modified version to support CUPS. If you have installed, say for instance lprng package, after CUPS, the lprng files would overwrite the CUPS versions. James On Thursday 25 December 2003 21:39, Carlos E. R. wrote:
Hi,
I can not stop print jobs.
I'm using SuSE 8.2 and cups:
cer@nimrodel:~> lpq -a Rank Owner Job File(s) Total Size active cer 332 (stdin) 26065920 bytes cer@nimrodel:~> lprm 332 cer@nimrodel:~> lpq -a no entries cer@nimrodel:~>
So there are no print jobs, but the printer goes on printing. I stop cups:
nimrodel:/var/spool/cups # rccups stop Shutting down cupsd done nimrodel:/var/spool/cups # rccups status Checking for cupsd: unused
But the printer continues printing. Why!?
I see a big file in '/var/spool/cups/tmp' dated now - I forgot to compare its size with the deleted job. I delete it... and printing continues. There is nothing under '/var/spool/lpd'
ps afxl|less shows a job:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 0 0 9178 1 15 0 2800 652 schedu S ? 0:03 parallel:/dev/lp0 332 cer (stdin)
I guess that the culprit must be "/usr/lib/cups/backend/parallel". Why wasn't it stopped when I stopped cups? Perhaps 'lprm' must be used as root?
Finally I stop the printer with "kill -9 9178" (the -9 seems to be needed). Then I can restart cups. Peace!
Is this a bug? SuSE 8.1 was also unable to stop print jobs (I asked here about it). Certainly stopping a print job should really stop it. To whom can this be reported?
The Friday 2003-12-26 at 20:07 -0500, James Finnall wrote:
Have you tried using the CUPS Web interface, http://localhost:631
Yes, I did. It complains of denied client access or something similar. Look at the log (/var/log/cups/error_log): I [03/Nov/2003:14:21:29 +0100] Started "/usr/lib/cups/cgi-bin/jobs.cgi" (pid=4234) E [03/Nov/2003:14:21:30 +0100] cancel_job: "" not authorized to delete job id 259 owned by "cer"! I [03/Nov/2003:14:21:51 +0100] Started "/usr/lib/cups/cgi-bin/printers.cgi" (pid=4238) I [03/Nov/2003:14:21:58 +0100] Started "/usr/lib/cups/cgi-bin/jobs.cgi" (pid=4239) E [03/Nov/2003:14:21:59 +0100] hold_job: "" not authorized to hold job id 259 owned by "cer"! See, it says it can not hold neither delete a job belonging to myself. See the log from yesterday morning (the one I reported about here): I [25/Dec/2003:12:22:51 +0100] Job 332 queued on 'lpg' by 'cer'. I [25/Dec/2003:12:22:51 +0100] Started filter /usr/lib/cups/filter/pstops (PID 3415) for job 332. I [25/Dec/2003:12:22:51 +0100] Started filter /usr/lib/cups/filter/cupsomatic (PID 3416) for job 332. I [25/Dec/2003:12:22:51 +0100] Started backend /usr/lib/cups/backend/parallel (PID 3417) for job 332. I [25/Dec/2003:12:41:55 +0100] Started "/usr/lib/cups/cgi-bin/jobs.cgi" (pid=3546) I [25/Dec/2003:12:43:24 +0100] Started "/usr/lib/cups/cgi-bin/jobs.cgi" (pid=3547) E [25/Dec/2003:12:43:25 +0100] hold_job: "" not authorized to hold job id 332 owned by "cer"! E [25/Dec/2003:12:44:27 +0100] Scheduler shutting down due to SIGTERM. You see, it said I could not hold the job - nevertheless, I think it was holded; anyways, I halted the computer, and as I was in a hurry and didn't take a note of it. Some other times, when I tried to cancel a job, it says it was canceled, disappearing from the job list, but the printer continued to print unabated. Different but similar results to the CLI. This time, when I switched on the computer some hours later, the job started again (job 332) - notice that this is the error log, and I have "LogLevel info", so not everything is logged. I [26/Dec/2003:00:09:36 +0100] LoadPPDs: Read "/etc/cups/ppds.dat", 3005 PPDs... I [26/Dec/2003:00:09:59 +0100] LoadPPDs: No new or changed PPDs... I [26/Dec/2003:00:10:02 +0100] Started filter /usr/lib/cups/filter/pstops (PID 2873) for job 332. I [26/Dec/2003:00:10:02 +0100] Started filter /usr/lib/cups/filter/cupsomatic (PID 2874) for job 332. I [26/Dec/2003:00:10:02 +0100] Started backend /usr/lib/cups/backend/parallel (PID 2875) for job 332. E [26/Dec/2003:03:06:11 +0100] Scheduler shutting down due to SIGTERM. Here I stopped and restarted CUPS some seconds later - job 332 restarts. I [26/Dec/2003:03:06:41 +0100] Listening to 0:631 I [26/Dec/2003:03:06:41 +0100] Configured for up to 100 clients. I [26/Dec/2003:03:06:41 +0100] Allowing up to 10 client connections per host. I [26/Dec/2003:03:06:41 +0100] LoadPPDs: Read "/etc/cups/ppds.dat", 3005 PPDs... I [26/Dec/2003:03:06:42 +0100] LoadPPDs: No new or changed PPDs... I [26/Dec/2003:03:06:42 +0100] Started filter /usr/lib/cups/filter/pstops (PID 9176) for job 332. I [26/Dec/2003:03:06:42 +0100] Started filter /usr/lib/cups/filter/cupsomatic (PID 9177) for job 332. I [26/Dec/2003:03:06:42 +0100] Started backend /usr/lib/cups/backend/parallel (PID 9178) for job 332. I [26/Dec/2003:03:07:42 +0100] Job 332 was cancelled by 'cer'. E [26/Dec/2003:03:08:30 +0100] Scheduler shutting down due to SIGTERM. I [26/Dec/2003:03:26:20 +0100] Listening to 0:631 I think that here I used the CLI to stop the job. As the printer continued printing after one minute (more than enough to empty its buffer in graphic mode), I stopped cups, and restarted it after I investigated and manually killed the "parallel" task (half a graphics page later).
I use it extensively with 8.1 and it will terminate the print jobs, including the backend. Then I either power off the printer or wait for the buffer to finish and then reset the printer.
Not here, it doesn't work. SuSE 8.1 also failed in this respect; I'm unsure if the symptoms were the same, but I asked about it on this list.
But, I agree that the CLI should work properly as well. May I suggest you verify that the lp tools are the programs supplied with CUPS.
They are, they are. SuSE supplied software all of them, standard release.
I suggest it because they have their own modified version to support CUPS. If you have installed, say for instance lprng package, after CUPS, the lprng files would overwrite the CUPS versions.
No, it is not that. Is your printer connected to the parallel port, or is it usb or a network device? Inkjet, or one that understand postscript directly? -- Cheers, Carlos Robinson
On Friday 26 December 2003 22:39, Carlos E. R. wrote:
Is your printer connected to the parallel port, or is it usb or a network device? Inkjet, or one that understand postscript directly?
I only have SuSE 8.1 installed on my notebook and I use it in the office. The printer would be connected through a USB/parallel converter. I also use CUPS under Slack 8.1 with my Epson photo printer connected through the parallel port. I thought the Slack system would have CUPS from a custom build but when I checked I installed from a Slack package, version 1.1.15. I am not sure about my notebook. I could have built a custom CUPS though to update the drivers section since I use it when I am repairing printers. The format of the printer would not really be an issue here, once ghostscript (if required) has run to produce the output file nothing left but sending the output file to the printer. However, I have canceled large photo jobs under the Slack system and the ghostscript child is canceled as well if it was still running. When printing to a remote lpd server, the job is gone so fast that it cannot be deleted on the local machine. Nothing left there to cancel or hold. As far as CUPS is concerned it is completed. The job has to be canceled manually on the remote lpd server. The following lines are the file info on my Slack system for some of the CUPS files. It would of been compiled on Jun 12, 2002. bash-2.05a# ls -l /usr/bin/lp root bin 11652 Jun 12 2002 /usr/bin/lp bash-2.05a# ls -l /usr/sbin/cupsd root bin 235404 Jun 12 2002 /usr/sbin/cupsd bash-2.05a# ls -l /usr/bin/lprm root bin 6700 Jun 12 2002 /usr/bin/lprm bash-2.05a# ls -l /usr/bin/cancel root bin 6992 Jun 12 2002 /usr/bin/cancel bash-2.05a# ls -l /usr/bin/lpstat root bin 18444 Jun 12 2002 /usr/bin/lpstat bash-2.05a# ls -l /usr/bin/lp root bin 11652 Jun 12 2002 /usr/bin/lp This is the date of the lpd daemon, it displays an earlier date, but doesn't match the CUPS programs. Originally the files would have matched to this daemon. But not after CUPS is installed. I think lpd is the only program CUPS doesn't replace. bash-2.05a# ls -l /usr/sbin/lpd root bin 22668 May 24 2002 /usr/sbin/lpd If your files are the ones from the distro and all match the way they should, perhaps a custom build of CUPS would resolve the problem. Sorry, I cannot help on the security issue, I always login as root. However, I think I did have to make some mods to the CUPS config in /etc/cups to get the some operations to work though. Not sure which ones though. The web interface now prompts me for the root login and password. If I recall I had to do this even though I was logged in as root. I thought it was about security issues for a web interface and some operations would require a 2nd authentication to enable them. Perhaps it will be of some help to you. James
The Saturday 2003-12-27 at 07:51 -0500, James Finnall wrote:
The format of the printer would not really be an issue here, once ghostscript (if required) has run to produce the output file nothing left but sending the output file to the printer.
True enough, but I'm grasping at straws here :-)
However, I have canceled large photo jobs under the Slack system and the ghostscript child is canceled as well if it was still running.
Before SuSE 8.1/8.2, when I did not use cups, I cold cancel jobs easily. The ghostscript child is no problem, that one ends before printing actually starts, I think. The problem is the child program that actually sends the data through the parallel port, that doesn't get killed.
When printing to a remote lpd server, the job is gone so fast that it cannot be deleted on the local machine. Nothing left there to cancel or hold. As far as CUPS is concerned it is completed. The job has to be canceled manually on the remote lpd server.
I suppose so. However, the client cups could perhaps talk to the server cups and stop the job. Not my case.
The following lines are the file info on my Slack system for some of the CUPS files. It would of been compiled on Jun 12, 2002.
bash-2.05a# ls -l /usr/bin/lp root bin 11652 Jun 12 2002 /usr/bin/lp bash-2.05a# ls -l /usr/sbin/cupsd root bin 235404 Jun 12 2002 /usr/sbin/cupsd bash-2.05a# ls -l /usr/bin/lprm root bin 6700 Jun 12 2002 /usr/bin/lprm
I would be interested on the permissions of this one. Any suid bits around?
If your files are the ones from the distro and all match the way they should, perhaps a custom build of CUPS would resolve the problem.
Sorry, I cannot help on the security issue, I always login as root.
Ah! I never do, that could be it. Next time, I'll try to stop the job as root. I have to run some more tests, enabling first debug logging of the cps daemon.
However, I think I did have to make some mods to the CUPS config in /etc/cups to get the some operations to work though. Not sure which ones though.
Yes, me too, for the web interface to work. Commented on the list months ago.
The web interface now prompts me for the root login and password. If I recall I had to do this even though I was logged in as root. I thought it was about security issues for a web interface and some operations would require a 2nd authentication to enable them.
It is, I guess, because the web interface doesn't know that you are root, till you log with it. It doesn't matter that the browser is running as root.
Perhaps it will be of some help to you.
Some ideas, yes, thanks. -- Cheers, Carlos Robinson
-----Original Message----- From: "Carlos E. R." <robin1.listas@tiscali.es> To: SLE <suse-linux-e@suse.com> Date: Sat, 27 Dec 2003 04:39:46 +0100 (CET) Subject: Re: [SLE] Stopping print jobs.
The Friday 2003-12-26 at 20:07 -0500, James Finnall wrote:
Have you tried using the CUPS Web interface, http://localhost:631
Yes, I did. It complains of denied client access or something similar. Look at the log (/var/log/cups/error_log):
I [03/Nov/2003:14:21:29 +0100] Started "/usr/lib/cups/cgi-bin/jobs.cgi" (pid=4234) E [03/Nov/2003:14:21:30 +0100] cancel_job: "" not authorized to delete job id 259 owned by "cer"! I [03/Nov/2003:14:21:51 +0100] Started "/usr/lib/cups/cgi-bin/printers.cgi" (pid=4238) I [03/Nov/2003:14:21:58 +0100] Started "/usr/lib/cups/cgi-bin/jobs.cgi" (pid=4239) E [03/Nov/2003:14:21:59 +0100] hold_job: "" not authorized to hold job id 259 owned by "cer"!
See, it says it can not hold neither delete a job belonging to myself. See the log from yesterday morning (the one I reported about here):
<snip> You did remember to add yourself as an admin using lppasswd didn't you? This was a popup notice when you installed cups. Ken
The Saturday 2003-12-27 at 10:04 -0500, Ken Schneider wrote:
You did remember to add yourself as an admin using lppasswd didn't you? This was a popup notice when you installed cups.
No, certainly I didn't. :-? I don't remember seeing that notice, and certainly it is not on the emails sent to root after install (I have just reviewed them), only one mentioning that cupsd.conf was saved as cupsd.conf.rpmnew. Mmm... reading the cups html admin doc, I see that lppasswd is needed for "Digest authentication", and I use "AuthType Basic". I don't need lppasswd, because I don't use passwords in "/etc/cups/passwd.md5" (no such file, anyway). And that works, because I can add and remove printers using the web interface from mozilla, and that requires higher privileges than removing a job, and any user must be allowed to remove his own jobs. Notice that cups allows me to remove print jobs, and the queue shows empty - but it doesn't kill the task that is really sending the data to the printer, so it continues printing. -- Cheers, Carlos Robinson
* Carlos E. R. <robin1.listas@tiscali.es> [12-28-03 09:35]:
The Saturday 2003-12-27 at 10:04 -0500, Ken Schneider wrote:
You did remember to add yourself as an admin using lppasswd didn't you? This was a popup notice when you installed cups.
No, certainly I didn't. :-? [snip ...]
CMIIANC, but Carlos uses 8.2, not 9.0 and accessing cups in 8.2 only requires root password, not lp password. A ver 9.0 security enhancement. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org
On Sun, 2003-12-28 at 15:58, Patrick Shanahan wrote:
* Carlos E. R. <robin1.listas@tiscali.es> [12-28-03 09:35]:
The Saturday 2003-12-27 at 10:04 -0500, Ken Schneider wrote:
You did remember to add yourself as an admin using lppasswd didn't you? This was a popup notice when you installed cups.
No, certainly I didn't. :-? [snip ...]
CMIIANC, but Carlos uses 8.2, not 9.0 and accessing cups in 8.2 only requires root password, not lp password. A ver 9.0 security enhancement.
I am also using 8.2 and the only things that work for stopping print jobs are the commands Lprm -P (printer name) to stop the job and fuser -k /dev/(device name of the printer)to remove what remains and could still be transmitted to the printer works with cups and no need to be root for this. hope this helps -- ________________ Paul Ollion Proud Linux user - SuSE - 8.2
The Sunday 2003-12-28 at 22:39 +0100, Paul Ollion wrote:
I am also using 8.2 and the only things that work for stopping print jobs are the commands
Lprm -P (printer name) to stop the job
or lprm job_number
and fuser -k /dev/(device name of the printer)to remove what remains and could still be transmitted to the printer
or killall -9 parallel
works with cups and no need to be root for this.
As user I can not kill the parallel task - that's the one using the port, I suppose. I'll try the fuser thing one day. -- Cheers, Carlos Robinson
The Sunday 2003-12-28 at 09:58 -0500, Patrick Shanahan wrote:
You did remember to add yourself as an admin using lppasswd didn't you? This was a popup notice when you installed cups.
No, certainly I didn't. :-?
CMIIANC, but Carlos uses 8.2, not 9.0 and accessing cups in 8.2 only requires root password, not lp password. A ver 9.0 security enhancement.
Ah, I see. Anyway, I got the web interface to at least _try_ to kill the jobs, there was a configuration error that account for the "access denied" error. The job now shows as canceled, but it continues printing - same result as with the cli. It has be killed manually by root. I just posted a long follow up on this. -- Cheers, Carlos Robinson
On Fri, 2003-12-26 at 16:07, James Finnall wrote:
Have you tried using the CUPS Web interface, http://localhost:631 I use it extensively with 8.1 and it will terminate the print jobs, including the backend. Then I either power off the printer or wait for the buffer to finish and then reset the printer.
But, I agree that the CLI should work properly as well. May I suggest you verify that the lp tools are the programs supplied with CUPS. I suggest it because they have their own modified version to support CUPS. If you have installed, say for instance lprng package, after CUPS, the lprng files would overwrite the CUPS versions.
James
On Thursday 25 December 2003 21:39, Carlos E. R. wrote:
Hi,
I can not stop print jobs.
I'm using SuSE 8.2 and cups:
cer@nimrodel:~> lpq -a Rank Owner Job File(s) Total Size active cer 332 (stdin) 26065920 bytes cer@nimrodel:~> lprm 332 cer@nimrodel:~> lpq -a no entries cer@nimrodel:~>
So there are no print jobs, but the printer goes on printing. I stop cups:
back in SuSe 7.x, the print command file was in /var/spool/lpd/y2prn_lp... (or whatever the printer was called). If the printer jammed, or was powered down while printing, then deleting the print file was the only way to stop the page after page with garbage lines. It never seemed right, but it worked for me. In 8.2 that print file appears to be /var/spoool/cups/d00225-001 when I just printed your email. /var/spool/cups/c00225 seems to be the record-keeper for that job. Does print cancellation remove your /var/spool/cups/xxxxx printfile?
nimrodel:/var/spool/cups # rccups stop Shutting down cupsd done nimrodel:/var/spool/cups # rccups status Checking for cupsd: unused
But the printer continues printing. Why!?
I see a big file in '/var/spool/cups/tmp' dated now - I forgot to compare its size with the deleted job. I delete it... and printing continues. There is nothing under '/var/spool/lpd'
ps afxl|less shows a job:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 0 0 9178 1 15 0 2800 652 schedu S ? 0:03 parallel:/dev/lp0 332 cer (stdin)
I guess that the culprit must be "/usr/lib/cups/backend/parallel". Why wasn't it stopped when I stopped cups? Perhaps 'lprm' must be used as root?
Finally I stop the printer with "kill -9 9178" (the -9 seems to be needed). Then I can restart cups. Peace!
Is this a bug? SuSE 8.1 was also unable to stop print jobs (I asked here about it). Certainly stopping a print job should really stop it. To whom can this be reported?
The Saturday 2003-12-26 at 19:41 -0900, Stanley Long wrote:
In 8.2 that print file appears to be /var/spoool/cups/d00225-001 when I just printed your email. /var/spool/cups/c00225 seems to be the record-keeper for that job. Does print cancellation remove your /var/spool/cups/xxxxx printfile?
No, it doesn't. I have to double check, but there was a file there of the approximate size. I deleted it, but printing continued... so I can not be sure if I deleted the right file, or the spooler already had it "memorized". I'll run a more detailed test tonight or tomorrow, with debugging logging info enabled. I can simply take the printer out of line while I carefully look around files and tasks, without wasting the expensive ink. When I do those tests, I'll repost on a new thread. -- Cheers, Carlos Robinson
"Carlos E. R." <robin1.listas@tiscali.es> writes:
I can not stop print jobs. I'm using SuSE 8.2 and cups ...
I had a similar problem with SuSE 8.2 too. I didn't have time to find what was wrong so I just rebooted the machine and the printing stopped. Apparently, there is a bug in CUPS in SuSE 8.2.
To whom can this be reported?
IMHO to CUPS developers. There is a trouble report form available in the support section of http://www.cups.org. -- A.M.
The Saturday 2003-12-27 at 15:05 +0100, Alexandr Malusek wrote:
I can not stop print jobs. I'm using SuSE 8.2 and cups ...
I had a similar problem with SuSE 8.2 too. I didn't have time to find what was wrong so I just rebooted the machine and the printing stopped. Apparently, there is a bug in CUPS in SuSE 8.2.
Ah, that would kill the "/usr/lib/cups/backend/parallel" task that was running. Yes, it shold work, provided you first removed the job from cups with lprm.
To whom can this be reported?
IMHO to CUPS developers. There is a trouble report form available in the support section of http://www.cups.org.
I'll research more first. It could be that this was known and resolved, the version in 8.2 must be old to them. -- Cheers, Carlos Robinson
[long mail] [some long lines > 80 chars] [conclusion at the end] The Friday 2003-12-26 at 03:39 +0100, Carlos E. R. wrote:
I can not stop print jobs.
Ok, I try again with full details. I have solved one thing, but the end result remains that I can not stop print jobs by "normal" means. First, I edit '/etc/cups/cupsd.conf', define "LogLevel debug2", and restart cups service. Then I print a photograph, I wait till printer start, then I manually put the printer off-line to have time to test without using ink. Tasks are (ps afx| less): |> 3671 ? S 0:00 \_ /usr/bin/perl /usr/lib/cups/filter/cupsomatic 335 cer (stdin) 1 |> 3674 ? S 0:00 | \_ /usr/bin/perl /usr/lib/cups/filter/cupsomatic 335 cer (stdin) 1 |> 3675 ? S 0:00 | \_ /usr/bin/perl /usr/lib/cups/filter/cupsomatic 335 cer (stdin) 1 |> 3676 ? S 0:00 | \_ sh -c gs '-dSAFER' '-dNOPAUSE' '-dBATCH' '-sDEVICE=stp' '-sModel=bjc-4300' '-sOutputFile=| cat >&3' '/dev/fd/0' 3>&1 1>&2 |> 3677 ? S 0:04 | \_ gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=stp -sModel=bjc-4300 -sOutputFile=| cat >&3 /dev/fd/0 |> 3678 ? S 0:00 | \_ sh -c cat >&3 |> 3679 ? S 0:00 | \_ cat |> 3672 ? S 0:02 \_ parallel:/dev/lp0 335 cer (stdin) 1 (/dev/fd/0 -> /dev/pts/14 -- its a tty, not the floppy; actually a "Unix98 pseudo-TTY") The web interface (http://localhost:631/jobs) shows: |> ID Name User Size State Control |> lpg-335 (stdin) cer 1536k processing since |> Sun Dec 28 23:42:47 2003 Hold Job Cancel Job First, I try to hold the job, and I get: |> "Error: client-error-forbidden" The '/var/log/cups/error_log' has this: (log heavily clipped, it is too long - prefix "d" seems to be the highest debug info, so I remove a lot of those lines) |> I [28/Dec/2003:23:42:47 +0100] Job 335 queued on 'lpg' by 'cer'. |> D [28/Dec/2003:23:42:47 +0100] Job 335 hold_until = 0 |> I [28/Dec/2003:23:42:47 +0100] Started filter /usr/lib/cups/filter/pstops (PID 3670) for job 335. |> I [28/Dec/2003:23:42:47 +0100] Started filter /usr/lib/cups/filter/cupsomatic (PID 3671) for job 335. |> I [28/Dec/2003:23:42:47 +0100] Started backend /usr/lib/cups/backend/parallel (PID 3672) for job 335. |> D [28/Dec/2003:23:44:19 +0100] CGI /usr/lib/cups/cgi-bin/jobs.cgi started - PID = 3682 |> I [28/Dec/2003:23:44:19 +0100] Started "/usr/lib/cups/cgi-bin/jobs.cgi" (pid=3682) |> D [28/Dec/2003:23:44:19 +0100] SendCommand() 3 file=7 |> D [28/Dec/2003:23:44:20 +0100] AcceptClient() 5 from localhost:631. |> D [28/Dec/2003:23:44:20 +0100] ReadClient() 8 GET /cups.css HTTP/1.1 |> d [28/Dec/2003:23:44:20 +0100] IsAuthorized: auth = 0, satisfy=0... |> d [28/Dec/2003:23:44:20 +0100] get_file() 8 filename=/usr/share/doc/packages/cups/cups.css size=-1 |> D [28/Dec/2003:23:44:20 +0100] SendError() 8 code=404 |> D [28/Dec/2003:23:44:20 +0100] CloseClient() 8 |> D [28/Dec/2003:23:44:20 +0100] ReadClient() 5 POST /jobs HTTP/1.1 |> d [28/Dec/2003:23:44:20 +0100] POST /jobs |> d [28/Dec/2003:23:44:20 +0100] CONTENT_TYPE = application/ipp |> d [28/Dec/2003:23:44:20 +0100] ReadClient() 5 con->data_encoding = length, con->data_remaining = 138, con->file = 0 |> d [28/Dec/2003:23:44:20 +0100] ProcessIPPRequest(0x404f1220[5]): operation_id = 000c |> d [28/Dec/2003:23:44:20 +0100] hold_job(0x404f1220[5], ipp://localhost/jobs/335) |> d [28/Dec/2003:23:44:20 +0100] validate_user(0x404f1220[5], "cer", 0xbfff2790, 1024) |> E [28/Dec/2003:23:44:20 +0100] hold_job: "" not authorized to hold job id 335 owned by "cer"! |> d [28/Dec/2003:23:44:20 +0100] send_ipp_error(0x404f1220[5], 401) |> D [28/Dec/2003:23:44:20 +0100] Sending error: client-error-forbidden |> D [28/Dec/2003:23:44:20 +0100] ProcessIPPRequest: 5 status_code=401 |> D [28/Dec/2003:23:44:20 +0100] CloseClient() 5 And the job remains listed, both on the CLI and on the web interface: |> cer@nimrodel:~> lpq -a |> Rank Owner Job File(s) Total Size |> active cer 335 (stdin) 1572864 bytes So, it is not put on hold. I try to cancel it, via web interface: I get: |> Error: client-error-forbidden And certainly, it is listed as running, both via web and CLI: |> cer@nimrodel:~> lpq -a |> Rank Owner Job File(s) Total Size |> active cer 335 (stdin) 1572864 bytes |> cer@nimrodel:~> lpstat |> lpg-335 cer 1572864 Sun 28 Dec 2003 11:42:47 PM CET The error log is very similar to what I got before, when I tried to put it on hold: |> d [29/Dec/2003:00:35:17 +0100] cancel_job(0x404f1220[5], ipp://localhost/jobs/335) |> d [29/Dec/2003:00:35:17 +0100] validate_user(0x404f1220[5], "cer", 0xbfff2790, 1024) |> E [29/Dec/2003:00:35:17 +0100] cancel_job: "" not authorized to delete job id 335 owned by "cer"! So I try to cancel the job via CLI: |> cer@nimrodel:~> lprm 335 |> cer@nimrodel:~> lpq -a |> no entries |> cer@nimrodel:~> At least this time it is reported as canceled. Log shows: |> d [29/Dec/2003:00:43:59 +0100] AcceptClient(0x808cc00) 0 NumClients = 0 |> D [29/Dec/2003:00:43:59 +0100] AcceptClient() 3 from localhost:631. |> d [29/Dec/2003:00:43:59 +0100] AcceptClient: Adding fd 3 to InputSet... |> d [29/Dec/2003:00:43:59 +0100] ReadClient() 3, used=0 |> D [29/Dec/2003:00:43:59 +0100] ReadClient() 3 POST / HTTP/1.1 |> d [29/Dec/2003:00:43:59 +0100] decode_auth(0x404ee008): Authorization string = "" |> d [29/Dec/2003:00:43:59 +0100] decode_auth() 3 username="" |> d [29/Dec/2003:00:43:59 +0100] IsAuthorized: con->uri = "/" |> d [29/Dec/2003:00:43:59 +0100] FindBest: uri = "/"... |> d [29/Dec/2003:00:43:59 +0100] FindBest: Location / Limit 7f |> d [29/Dec/2003:00:43:59 +0100] FindBest: Location /admin Limit 7f |> d [29/Dec/2003:00:43:59 +0100] FindBest: best = "/" |> d [29/Dec/2003:00:43:59 +0100] IsAuthorized: auth = 0, satisfy=0... ... (many lines later, but the same timestamp) |> d [29/Dec/2003:00:43:59 +0100] ReadClient() 5 con->data_encoding = length, con->data_remaining = 1, con->file = 0 |> d [29/Dec/2003:00:43:59 +0100] ProcessIPPRequest(0x404f1220[5]): operation_id = 0008 |> d [29/Dec/2003:00:43:59 +0100] cancel_job(0x404f1220[5], ipp://localhost/jobs/335) |> d [29/Dec/2003:00:43:59 +0100] validate_user(0x404f1220[5], "cer", 0xbfff2790, 1024) |> D [29/Dec/2003:00:43:59 +0100] CancelJob: id = 335 |> D [29/Dec/2003:00:43:59 +0100] StopJob: id = 335, force = 0 |> D [29/Dec/2003:00:43:59 +0100] StopJob: printer state is 3 |> d [29/Dec/2003:00:43:59 +0100] StopJob: Removing fd 6 from InputSet... |> d [29/Dec/2003:00:43:59 +0100] StopJob: Freeing status buffer... |> d [29/Dec/2003:00:43:59 +0100] PID 3671 exited with no errors. |> I [29/Dec/2003:00:43:59 +0100] Job 335 was cancelled by 'cer'. |> D [29/Dec/2003:00:43:59 +0100] ProcessIPPRequest: 5 status_code=0 However, "ps afx|less" shows this is not true: |> 3592 ? S 0:07 /usr/sbin/cupsd -c /etc/cups/cupsd.conf |> 3672 ? S 0:02 \_ parallel:/dev/lp0 335 cer (stdin) 1 And the process doesn't die stopping cups or restarting it. It has to be killed with signal -9 Configuration is (/etc/cups/cupsd.conf): |> LogLevel debug2 |> HostNameLookups On |> |> <Location /> |> Order Deny,Allow |> Deny From All |> Allow From 127.0.0.1 |> Allow From 127.0.0.2 |> Allow From 192.168.100.2 |> </Location> |> |> |> <Location /jobs> |> # |> # You may wish to limit access to job operations, either with Allow |> # and Deny lines, or by requiring a username and password. |> # |> #</Location> |> |> <Location /admin> |> AuthType Basic |> AuthClass System |> Order Deny,Allow |> Deny From All |> Allow From 127.0.0.1 |> Allow From 192.168.100.2 |> </Location> Mmmm... I think I know why the web interface doesn't stop jobs, it must be because the configuration for "jobs" is empty. I change to: |> <Location /jobs> |> AuthType Basic |> AuthClass System |> Order Deny,Allow |> Deny From All |> Allow From 127.0.0.1 |> Allow From 192.168.100.2 |> </Location> Ah, now the web interface asks me for user/password before showing me the job list - although it doesn't accept my normal user password (but it does accept root's). Let's try a change: |> AuthClass User and now it does. Lets see if I can stop jobs It says it does! |> Jobs |> |> Job 337 has been cancelled. But it goes on printing :-( |> nimrodel:~ # lpq -a |> no entries The log shows: |> d [29/Dec/2003:01:30:23 +0100] IsAuthorized: auth = 0, satisfy=0... |> d [29/Dec/2003:01:30:23 +0100] IsAuthorized: username = "cer" password = 0 chars |> d [29/Dec/2003:01:30:23 +0100] IsAuthorized: Checking "cer", address = 7f000001, hostname = "localhost" |> d [29/Dec/2003:01:30:23 +0100] IsAuthorized: Checking user membership... |> d [29/Dec/2003:01:30:23 +0100] POST /jobs |> d [29/Dec/2003:01:30:23 +0100] CONTENT_TYPE = application/ipp |> d [29/Dec/2003:01:30:23 +0100] ReadClient() 7 con->data_encoding = length, con->data_remaining = 141, con->file = 0 |> d [29/Dec/2003:01:30:23 +0100] ProcessIPPRequest(0x404f4438[7]): operation_id = 0008 |> d [29/Dec/2003:01:30:23 +0100] cancel_job(0x404f4438[7], ipp://localhost/jobs/337) |> d [29/Dec/2003:01:30:23 +0100] validate_user(0x404f4438[7], "cer", 0xbfff2790, 1024) |> D [29/Dec/2003:01:30:23 +0100] CancelJob: id = 337 |> D [29/Dec/2003:01:30:23 +0100] StopJob: id = 337, force = 0 |> D [29/Dec/2003:01:30:23 +0100] StopJob: printer state is 3 |> d [29/Dec/2003:01:30:23 +0100] PID 5727 exited with no errors. |> d [29/Dec/2003:01:30:23 +0100] StopJob: Removing fd 6 from InputSet... |> d [29/Dec/2003:01:30:23 +0100] StopJob: Freeing status buffer... |> I [29/Dec/2003:01:30:23 +0100] Job 337 was cancelled by 'cer'. |> D [29/Dec/2003:01:30:23 +0100] ProcessIPPRequest: 7 status_code=0 |> d [29/Dec/2003:01:30:23 +0100] WriteClient: Removing fd 7 from OutputSet... |> d [29/Dec/2003:01:30:24 +0100] PID 5762 exited with no errors. |> d [29/Dec/2003:01:30:24 +0100] DeleteCert: removing certificate for pid 5762 |> d [29/Dec/2003:01:30:24 +0100] ReadClient() 7, used=0 |> D [29/Dec/2003:01:30:24 +0100] CloseClient() 7 Ok, so the authorization problem is solved. But it refuses to really stop printing. The only way is to manually kill task 'parallel' |> 5648 ? S 0:04 /usr/sbin/cupsd -c /etc/cups/cupsd.conf |> 5728 ? S 0:03 \_ parallel:/dev/lp0 337 cer (stdin) 1 |> 5730 ? S 0:00 /usr/bin/perl /usr/lib/cups/filter/cupsomatic 337 cer (stdin) 1 |> 5731 ? S 0:00 \_ /usr/bin/perl /usr/lib/cups/filter/cupsomatic 337 cer (stdin) 1 |> 5732 ? S 0:00 \_ sh -c gs '-dSAFER' '-dNOPAUSE' '-dBATCH' '-sDEVICE=stp' '-sModel=bjc-4300' '-sOutputFile=| cat >&3' '/dev/fd/0' 3>&1 1>&2 |> 5733 ? S 0:05 \_ gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=stp -sModel=bjc-4300 -sOutputFile=| cat >&3 /dev/fd/0 |> 5759 ? S 0:00 \_ sh -c cat >&3 |> 5760 ? S 0:00 \_ cat Ok, final test for today: I'll try to stop a print job being root. |> nimrodel:~ # lpq -a |> Rank Owner Job File(s) Total Size |> active cer 338 (stdin) 1572864 bytes |> nimrodel:~ # lprm 338 |> nimrodel:~ # lpq -a |> no entries Web interface doesn't show job 338 - but it continues printing: |> 5648 ? S 0:06 /usr/sbin/cupsd -c /etc/cups/cupsd.conf |> 5787 ? S 0:01 \_ parallel:/dev/lp0 338 cer (stdin) 1 |> 5788 ? S 0:00 /usr/bin/perl /usr/lib/cups/filter/cupsomatic 338 cer (stdin) 1 |> 5789 ? S 0:00 \_ /usr/bin/perl /usr/lib/cups/filter/cupsomatic 338 cer (stdin) 1 |> 5790 ? S 0:00 \_ sh -c gs '-dSAFER' '-dNOPAUSE' '-dBATCH' '-sDEVICE=stp' '-sModel=bjc-4300' '-sOutputFile=| cat >&3' '/dev/fd/0' 3>&1 1>&2 |> 5792 ? S 0:02 \_ gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=stp -sModel=bjc-4300 -sOutputFile=| cat >&3 /dev/fd/0 |> 5793 ? S 0:00 \_ sh -c cat >&3 |> 5794 ? S 0:00 \_ cat restart cupsd - doesn't work. Manually kill 'parallel' (as root): yes. Final conclusion: ================== Regardless how I do it (cups web interface, command line) I can not hold, nor cancel print jobs. They are reported as canceled, but they continue printing. The child program that is spooling to the parallel port continues to run and has to be manually killed by root with signal -9 I use SuSE 8.2 and cups rpm is version cups-1.1.18-82 -- Cheers, Carlos Robinson
participants (8)
-
Alexandr Malusek -
Carlos E. R. -
James Finnall -
Ken Schneider -
Kenneth Schneider
-
Patrick Shanahan -
Paul Ollion -
Stanley Long