Cleaning cups queue through ssh [SUSE 8.2]
Hi, My mom has the problem that everytime she turns on her computer, it sends the very same job "automatically" to the printer. So in fact there is no chance to print anything else, because after the first page of that particular doc she used to turn OFF the printer! As I understood, she has to, otherwise gets just copies of that previous doc... I guess she sent the same job few times to the printer and that's why its coming constantly; anyway turning off the printer helps only to save paper, but seemingly does not solve the situation :( Please any ideas to make her comp forget about ALL the cups-jobs?! I have ssh access to that comp; anything else she could do locally. Thank you, Pelibali
Please any ideas to make her comp forget about ALL the cups-jobs?! I have ssh access to that comp; anything else she could do locally.
The way I do it with ssh is ssh into the box then su enter root password. then killall cupsd ( kills the print deamon). then open up mc. Then move to the var directory, then spool, then cups. That should put you in the cups directory where the files are stored for each print job. I delete everything in that directory with F8 . You have to do each file there one at a time. after they are all gone then cupsd to restart the cups print deamon. Give that a try an see if it clears out the queue for her. Hth. It works for me, might a shorter an easier way but that should work for you. jack malone Network Administrator EAST TEXAS LIGHTHOUSE FOR THE BLIND dba HORIZON INDUSTRIES 903-595-3444 http://www.horizonind.com
On Fri, 05 May 2006 15:12:27 -0500 Jack Malone <.> wrote:
The way I do it with ssh is ssh into the box then su enter root password. then killall cupsd ( kills the print deamon). then open up mc. Then move to the var directory, then spool, then cups. That should put you in the cups directory where the files are stored for each print job. I delete everything in that directory with F8 . You have to do each file there one at a time. after they are all gone then cupsd to restart the cups print deamon.
Thank you, this did the trick! Almost the same suggestion arrived to me from Paul C. as well in private. Regards, Pelibali
On Fri, 05 May 2006 15:12:27 -0500
Jack Malone <.> wrote:
The way I do it with ssh is ssh into the box then su enter root password. then killall cupsd ( kills the print deamon). then open up mc. Then move to the var directory, then spool, then cups. That should put you in the cups directory where the files are stored for each print job. I delete everything in that directory with F8 . You have to do each file there one at a time. after they are all gone then cupsd to restart the cups print deamon.
Thank you, this did the trick! Almost the same suggestion arrived to me from Paul C. as well in private.
Regards, Pelibali if you can get to the above mentioned directory and log in as root. You can use rm c* (at least on my system all the files there start with a c. them change directory to the /tmp in the cups directory and clear all the entries
On Sunday 07 May 2006 09:14, pelibali wrote: there with a rm x* where x is the first copy of characters of the file names. This works for me. Hope this is easier than all the f8's if you have alot of files. -- Russ
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, When I turn my firewall on with the setting to allow samba server I am not able to resolve a windows computer's name on my network. Could anybody please tell me what should I also allow for the name resolution to happen? Thanks, Arun -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEY3RM/ImPbuYUWasRAsX8AKDK+95zbfqzn5HVlURvuooC5if5zACdFnnq muhipnUn1UPwAv0frovOOjM= =1cGU -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have asked this question once before but didnt evoke a response. So I am posting it again. When I turn my firewall on with the setting to allow samba server, I am not able to resolve a windows computer's name on my network. Could anybody please tell me what should I also allow for the name resolution to happen? I am using SUSE 10.0 on Dell 9150 using a 2.6.13-15.8-smp kernel Thanks, Arun -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEa3O9/ImPbuYUWasRAnWTAJ0VhziDoh9FlXh+Zsdnidou9J19DQCgh8Z/ EWE5J8WX6yVJ29Cs0pLEMEA= =kVY6 -----END PGP SIGNATURE-----
Hi,
My mom has the problem that everytime she turns on her computer, it sends the very same job "automatically" to the printer. So in fact there is no chance to print anything else, because after the first page of that particular doc she used to turn OFF the printer! As I understood, she has to, otherwise gets just copies of that previous doc... I guess she sent the same job few times to the printer and that's why its coming constantly; anyway turning off the printer helps only to save paper, but seemingly does not solve the situation :(
Please any ideas to make her comp forget about ALL the cups-jobs?! I have ssh access to that comp; anything else she could do locally.
Thank you, Pelibali If you or your mother have root authority, sign on as root or su to root. Then go to /var/spool/cups. Clear the jobs there and in the /tmp directory. I'm
On Friday 05 May 2006 10:31, pelibali wrote: pretty sure this will clear all the spooled jobs. Hope this helps. -- Russ
Hello, On May 5 18:53 Russbucket wrote (shortened):
Please any ideas to make her comp forget about ALL the cups-jobs?! ... If you or your mother have root authority, sign on as root or su to root. Then go to /var/spool/cups. Clear the jobs there and in the /tmp directory. I'm
On Friday 05 May 2006 10:31, pelibali wrote: pretty sure this will clear all the spooled jobs.
And additionally if may let cupsd crash if you didn't stop it before because cupsd keeps a lot of information only in the main memory, see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell See http://lists.suse.com/archive/suse-linux-e/2004-Jun/4134.html how to remove CUPS' spool files. By the way: Why does "cancel -a" and/or "cancel -u" not work? Finally see our manual /usr/share/doc/manual/suselinux-manual_en/manual/index.html "Printer Operation" -> "Troubleshooting" -> "Defective Print Jobs and Data Transfer Errors" Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-05-08 at 12:00 +0200, Johannes Meixner wrote:
By the way: Why does "cancel -a" and/or "cancel -u" not work?
I was going to suggest "lpq" and then "lprm JOBNUMBER". However, I find that although the job disappears from the queue (lpq shows nothing), 90% of the times my printer continues printing, and I have to "kill -9" as root the "parallel" job that is printing to the parallel port. I don't know why, but it has been so for ages. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEX9kUtTMYHG2NR9URAmvMAKCFhNPVZ7Z8Cs7XFVY+rjWrLQ/E5ACfdorV xC4+uczP/k/x6mFNwwhqjoY= =kbF7 -----END PGP SIGNATURE-----
Hello, On May 9 01:49 Carlos E. R. wrote (shortened):
I was going to suggest "lpq" and then "lprm JOBNUMBER". However, I find that although the job disappears from the queue (lpq shows nothing), 90% of the times my printer continues printing, and I have to "kill -9" as root the "parallel" job that is printing to the parallel port. I don't know why, but it has been so for ages.
The "parallel" process is the CUPS backend which keeps running. The backend must keep running so that the filter could send a termination sequence to the printer to reset it. Regarding filter and backend in general, see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "The Filter" versus "The Backends". The problem is how to interrupt a printing job and leave the printer in a clean state so that it is ready to print the next job. Often this is simply not possible with generic printer drivers. Often printing on a low-level inkjet printer with a generic driver means that the driver sets up the printer to receive e.g. 12345678 bytes of binary graphics data and then send the 12345678 bytes of binary graphics data. Then the printer will interpret and print the next 12345678 bytes as graphics. When this job is interrupted e.g. after 2345678 bytes, the printer is still waiting for 10000000 bytes which it will interpret and print as graphics. I.e. the tricky part is how to tell a printer which is in graphics printing mode to switch back to its normal mode. This is very model specific and generic printer drivers don't support it. And don't rely on that even model specific drivers support it in any case. You ask for more details? You get more details ;-) Here we are (from a mail on the gimp-print-devel mailing list): ----------------------------------------------------------------------- ... Cc: gimp-print-devel@lists.sourceforge.net Subject: Re: [Gimp-print-devel] Cancelling printing Date: Tue, 9 May 2006 09:22:10 +0800 (CST) From: ... The real problem I am having is if I succesfully cancel a print job in cups, my Epson Photo 830 stops, leaving the cartiage in the air in the middle, wait 3 mins, cartiage back to the printer, and no more respond, it simply dead there ignoring anything sent from cups and keep flashing blue LED, the only way to solve it is to code-boot the printer and restart CUPS service. This doesn't seem to happen on my PS laserjet printer. I think cups is lacking a good way to handle communication to the Inkjet printer which already started their job. Don't know if this is cups problem or gutenprint enhancement. As usual when it comes to printing, it's a bit more complicated than it looks at first glance. The answer's different when you're printing from the GIMP, Cinepaint, or PhotoPrint than it is when you're printing from anything else. The Print plugins for the GIMP and Cinepaint, and PhotoPrint as a whole, are linked directly against Gutenprint and generate the raw printer data in the application. CUPS doesn't know anything about the contents of the data; it just sees a stream of bits and feeds them to the printer. If you abort the job, it just stops sending data. The only way out is to power cycle the printer, although I don't know why you'd need to restart CUPS. When printing from "conventional" applications, the application generates PDF (or Postscript, or some kind of well-known image format), which it sends to CUPS. CUPS creates a chain of filters and back ends; the most interesting ones are the filter that generates raster format (pstoraster, imagetoraster); the one that generates printer-specific data; and the back end that actually sends the data to the printer (parallel, usb, whatnot). The filter that generates printer-specific data is actually the most interesting, at least from my point of view. It takes raster data on its stdin and sends printer-specific output to its stdout. One of these filters is named rastertoprinter (in Gimp-Print 4.2) or rastertogutenprint.5.0 (in Gutenprint 5.0). This is the piece that's linked against Gutenprint. In this situation, you can abort a job cleanly (most of the time, at any rate). In this case, when you abort the job, what should happen is that the top level filter gets killed, which cuts off its output. The next filter sees that its input is cut off and cuts off its output. When the Gutenprint filter sees that its input has been cut off prematurely, it aborts the job cleanly (sending the correct termination sequence). You can do this by selecting the Postscript output driver in the Cinepaint print plugin; the problem with doing this is that you lose a lot of the nice features of Gutenprint because we haven't implemented them in the Postscript driver. This is an improvement that we want to make, but didn't get to in time for 5.0. Hopefully we'll finally get to it in the next release. ----------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-05-09 at 11:11 +0200, Johannes Meixner wrote:
On May 9 01:49 Carlos E. R. wrote (shortened):
I was going to suggest "lpq" and then "lprm JOBNUMBER". However, I find that although the job disappears from the queue (lpq shows nothing), 90% of the times my printer continues printing, and I have to "kill -9" as root the "parallel" job that is printing to the parallel port. I don't know why, but it has been so for ages.
The "parallel" process is the CUPS backend which keeps running. The backend must keep running so that the filter could send a termination sequence to the printer to reset it. Regarding filter and backend in general, see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "The Filter" versus "The Backends".
Yes. So far, I knew, more or less.
The problem is how to interrupt a printing job and leave the printer in a clean state so that it is ready to print the next job. ... ... is still waiting for 10000000 bytes which it will interpret and print as graphics. I.e. the tricky part is how to tell a printer which is in graphics printing mode to switch back to its normal mode. This is very model specific and generic printer drivers don't support it. And don't rely on that even model specific drivers support it in any case.
Ah!
You ask for more details? You get more details ;-) Here we are (from a mail on the gimp-print-devel mailing list):
Ah.... :-o (mouth hanging open, then clanking shut. You got me flummoxed :-) Ok, then... what about an option somewhere in "cancel" or wherever to also kill (or whateveris needed) the backend, at the user's risk? In me case, I know I have got to go to the printer and tell it to eject the current page, that readies it. Another idea. There is a "reset" line in the parallel cable going to the printer. If it works, you notice it by the printer "resetting" when the computer is powered up - in fact, if I boot W98 with my printer on, it resets two or three times, as windows goes by it different boot processes. Touching that line after emptying the buffer might work for some printers: it could be a configuration option enabled somewhere (admin decision). - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEYLRMtTMYHG2NR9URAr0XAJ9N53XzpMBKoefUiGPk3p19NwEXTACgh8RW HisRJdQLOotXyjzdMGziFCw= =rFI3 -----END PGP SIGNATURE-----
Hello, On May 9 17:24 Carlos E. R. wrote (shortened):
what about an option somewhere in "cancel" or wherever to also kill (or whateveris needed) the backend, at the user's risk? ... Another idea. There is a "reset" line in the parallel cable going to the printer. If it works, you notice it by the printer "resetting" when the computer is powered up - in fact, if I boot W98 with my printer on, it resets two or three times, as windows goes by it different boot processes. Touching that line after emptying the buffer might work for some printers: it could be a configuration option enabled somewhere (admin decision).
Both ideas seem to make sense, in particular because it is optional (i.e. it should not cause new unexpected problems). Feel free to send an enhancement request directly to CUPS via http://www.cups.org/str.php -> [ Submit Bug or Feature Request ] Kind Regards, Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
On Tue, 2006-05-09 at 01:49 +0200, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Monday 2006-05-08 at 12:00 +0200, Johannes Meixner wrote:
By the way: Why does "cancel -a" and/or "cancel -u" not work?
I was going to suggest "lpq" and then "lprm JOBNUMBER".
However, I find that although the job disappears from the queue (lpq shows nothing), 90% of the times my printer continues printing, and I have to "kill -9" as root the "parallel" job that is printing to the parallel port.
I don't know why, but it has been so for ages.
Just because you turn off the spigot does not mean the hose is instantly empty. The job is queued in memory on the printer and needs to empty from memory on the printer before stopping, the job has been removed from the PC but not from the printer. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-05-09 at 11:26 -0400, Ken Schneider wrote:
Just because you turn off the spigot does not mean the hose is instantly empty. The job is queued in memory on the printer and needs to empty from memory on the printer before stopping, the job has been removed from the PC but not from the printer.
No, that's not the case. When I delete the print job via cups, there remains a task (parallel) that keeps sending data to the parallel port printer - the full print job, in fact. The printer memory doesn't affect this. See Johannes Meixner mail for the explanation. The reason is, roughly, that that task has got only the raw data to send blindly to the port, and doesn't know the points where it can be safely interrupted. More or less. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEYO+TtTMYHG2NR9URAgjfAJ9mhLHByLsYTYRkUh5ACUDphPYLngCfUKjr nOQZaMwnjOq+WykKgm+HFH8= =XrDY -----END PGP SIGNATURE-----
Hi gurus.... One stupid question: Which is the version of Tomcat in openSUSE 10.1 RC3???
--- Lawrence Ferreira
Hi gurus....
One stupid question:
Which is the version of Tomcat in openSUSE 10.1 RC3???
You should be able to tell that in YaST look at the technical data or the package name. George
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I know, I know...
but I don't wanna download, install and check the tomcat version, just
to see if the version is good for my applications...
Can someone who have the openSUSE 10.1 RC3 installed check the tomcat
version please!?
Thanks
_____________________________________________
Lawrence Ferreira
AIX, HP-UX and SuSE Linux Enterprise Server Administrator
LINUX User (openSUSE-10.0 & SLES9) #271016
LPIC-1 - Linux Certified Professional
On 5/9/06, George Stoianov
--- Lawrence Ferreira
wrote: Hi gurus....
One stupid question:
Which is the version of Tomcat in openSUSE 10.1 RC3???
You should be able to tell that in YaST look at the technical data or the package name. George
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Tue, 2006-05-09 at 19:49 -0300, Lawrence Ferreira wrote:
I know, I know...
but I don't wanna download, install and check the tomcat version, just to see if the version is good for my applications...
Can someone who have the openSUSE 10.1 RC3 installed check the tomcat version please!?
Thanks
tomcat5-5.0.30-27.noarch.rpm -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
On Tue, 2006-05-09 at 19:06 -0400, Ken Schneider wrote:
On Tue, 2006-05-09 at 19:49 -0300, Lawrence Ferreira wrote:
I know, I know...
but I don't wanna download, install and check the tomcat version, just to see if the version is good for my applications...
Can someone who have the openSUSE 10.1 RC3 installed check the tomcat version please!?
Thanks
tomcat5-5.0.30-27.noarch.rpm
This is in the factory tree, not on RC3. Sorry. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
participants (9)
-
Arun Mallikarjunan
-
Carlos E. R.
-
George Stoianov
-
Jack Malone
-
Johannes Meixner
-
Ken Schneider
-
Lawrence Ferreira
-
pelibali
-
Russbucket