(*** This bug was imported into bugs.kde.org ***) Package: kcmprintmgr Version: KDE 3.0.5 (CVS HEAD >= 20020427) Severity: wishlist Installed from: compiled sources Compiler: gcc version 2.95.3 20010315 (SuSE) OS: Linux (i686) release 2.4.18-4GB OS/Compiler notes: Hi! fuser -k /dev/<pritner-device> would kill all processes fill many pages sending wired charcters to the printer after a disruption of the communication between the printserver and the printer. Do you see a possiblitiy to implement it ? cu ferdinand PS I have already seen so many people wasting so much paper because they didn't know this command especialy home users! (Submitted via bugs.kde.org) (Called from KBugReport dialog)
> Hi! > fuser -k /dev/<pritner-device> would kill all processes fill many pages sending wired charcters to the printer after a disruption of the communication between the printserver and the printer. > Do you see a possiblitiy to implement it ? > cu > ferdinand > > PS I have already seen so many people wasting so much paper because they didn't know this command especialy home users! I didn't know neither :-) The first idea that come to my mind is to implement it as for escputil support. I'll think about it. Michael. -- ------------------------------------------------------------------ Michael GoffioulIMEC-DESICS-MIRA e-mail: goffioul@imec.be(Mixed-Signal and RF Applications) Tel: +32/16/28-8510Kapeldreef 75 Fax: +32/16/28-15153001 HEVERLEE BELGIUM ------------------------------------------------------------------
On Monday 10 June 2002 09:07 Michael Goffioul wrote: > > Hi! > > fuser -k /dev/<pritner-device> would kill all processes fill many pages > > sending wired charcters to the printer after a disruption of the > > communication between the printserver and the printer. Do you see a > > possiblitiy to implement it ? > > cu > > ferdinand > > > > PS I have already seen so many people wasting so much paper because they > > didn't know this command especialy home users! > > I didn't know neither :-) > The first idea that come to my mind is to implement it as for escputil > support. I'll think about it. > > Michael. 1) I didn't check if this command needs administartor rigths. 2) IMHO it should go to a more prominent place because users (including me) tend to panic if printers go wild. Have you ever seen a fast laser printer throwing out 20 pages/minute with only one line of hyroglyphes? IMHO RMB first line would be the best place "Emergency Stop". May be it also needs a "Stop printer" command first and a short explanation what to do afterwards. -- cu ferdinand on SuSE 7.0 KDE 3.0 BRANCH
> 1) I didn't check if this command needs administartor rigths. > 2) IMHO it should go to a more prominent place because users (including me) > tend to panic if printers go wild. Have you ever seen a fast laser printer > throwing out 20 pages/minute with only one line of hyroglyphes? > IMHO RMB first line would be the best place "Emergency Stop". > May be it also needs a "Stop printer" command first and a short explanation > what to do afterwards. There are a few things that I dislike a little bit to make it very proeminent. First I wonder about availability of that utility as well as its portability across various UNIX systems. Second it probably requires administrator rights (located in /sbin) if you want to kill someone else's process. Third this "emergency" stop actually kills any process using a specified file (block device in this case). It does not stop the printer itself. I mean that even if the communication is broken the printer will still empty its internal buffer producing a lot of wasted paper. Sometimes it's possible to avoid this by sending a specified data sequence to the printer but it's printer specific. What I mean is that when you cancel a job in CUPS the server will terminate the child process that sends the data to the printer. "fuser" will do the same in a more brute way. As I think that the wasted paper after a job has been cancelled comes from the printer's internal buffer the use of "fuser" shouldn't change a lot. Michael. -- ------------------------------------------------------------------ Michael GoffioulIMEC-DESICS-MIRA e-mail: goffioul@imec.be(Mixed-Signal and RF Applications) Tel: +32/16/28-8510Kapeldreef 75 Fax: +32/16/28-15153001 HEVERLEE BELGIUM ------------------------------------------------------------------
On Monday 10 June 2002 11:00 Michael Goffioul wrote: > > 1) I didn't check if this command needs administartor rigths. > > 2) IMHO it should go to a more prominent place because users (including > > me) tend to panic if printers go wild. Have you ever seen a fast laser > > printer throwing out 20 pages/minute with only one line of hyroglyphes? > > IMHO RMB first line would be the best place "Emergency Stop". > > May be it also needs a "Stop printer" command first and a short > > explanation what to do afterwards. > > There are a few things that I dislike a little bit to make it very > proeminent. First I wonder about availability of that utility as well > as its portability across various UNIX systems. > Second it probably requires administrator rights (located in /sbin) > if you want to kill someone else's process. > Third this "emergency" stop actually kills any process using a specified > file (block device in this case). It does not stop the printer itself. > I mean that even if the communication is broken the printer will still > empty its internal buffer producing a lot of wasted paper. Sometimes > it's possible to avoid this by sending a specified data sequence to the > printer but it's printer specific. What I mean is that when you cancel > a job in CUPS the server will terminate the child process that sends > the data to the printer. "fuser" will do the same in a more brute way. > As I think that the wasted paper after a job has been cancelled comes > from the printer's internal buffer the use of "fuser" shouldn't change > a lot. Up to now I always ended up with a process sending data to the printer even after halting the printer with cups but may be this has changed in cups 1.15 didn't try (for obvious reasons). I always had to kill provesses manualy. > > Michael. -- cu ferdinand on SuSE 7.0 KDE 3.0 BRANCH
> Up to now I always ended up with a process sending data to the printer even > after halting the printer with cups but may be this has changed in cups 1.15 > didn't try (for obvious reasons). I always had to kill provesses manualy. Even after cancelling the running print job? (I don't mean stopping the printer). Because when stopping the printer CUPS will continue to process its current job no new job being processed afterwards. Michael. -- ------------------------------------------------------------------ Michael GoffioulIMEC-DESICS-MIRA e-mail: goffioul@imec.be(Mixed-Signal and RF Applications) Tel: +32/16/28-8510Kapeldreef 75 Fax: +32/16/28-15153001 HEVERLEE BELGIUM ------------------------------------------------------------------
On Monday 10 June 2002 14:01 Michael Goffioul wrote: > > Up to now I always ended up with a process sending data to the printer > > even after halting the printer with cups but may be this has changed in > > cups 1.15 didn't try (for obvious reasons). I always had to kill > > provesses manualy. > > Even after cancelling the running print job? (I don't mean stopping the > printer). Because when stopping the printer CUPS will continue to process > its current job no new job being processed afterwards. Yes I think even after canceling all print jobs. But as I said may be that has changed recently. Or the canceling user didn't have the permission to kill the job? IMHO the problem is that cups might loose trak if something goes wrong and can't kill the job any more. Canceling a job works fine if everything runs as expected. > > Michael. -- cu ferdinand on SuSE 7.0 KDE 3.0 BRANCH
Ferdinand Gassauer wrote: > > On Monday 10 June 2002 14:01 Michael Goffioul wrote: > > > Up to now I always ended up with a process sending data to the printer > > > even after halting the printer with cups but may be this has changed in > > > cups 1.15 didn't try (for obvious reasons). I always had to kill > > > provesses manualy. > > > > Even after cancelling the running print job? (I don't mean stopping the > > printer). Because when stopping the printer CUPS will continue to process > > its current job no new job being processed afterwards. > Yes I think even after canceling all print jobs. But as I said may be that > has changed recently. Or the canceling user didn't have the permission to > kill the job? > IMHO the problem is that cups might loose trak if something goes wrong and > can't kill the job any more. > Canceling a job works fine if everything runs as expected. I checked CUPS code. When the CUPS server receives a "CancelJob" request it sends a SIGTERM signal to all processes included in the print chain (filters rasterizer and backend). A SIGKILL signal is only sent when cancelling all jobs which probably only occurs on server shutdown. If some process still exists after the job has been cancelled this probably means that sit couldn't handle the SIGTERM process. Do you have an example of situation when this does not work as expected? Michael. -- ------------------------------------------------------------------ Michael GoffioulIMEC-DESICS-MIRA e-mail: goffioul@imec.be(Mixed-Signal and RF Applications) Tel: +32/16/28-8510Kapeldreef 75 Fax: +32/16/28-15153001 HEVERLEE BELGIUM ------------------------------------------------------------------