VIELE Druckerjobs löschen

[PatrickBaer]

Servus,

klitzekleines Problem, vielleicht hat jemand eine Lösung parat:

Eine Anwendung lief ein "bisschen" Amok und hat im 10minütigen Abstand etwa 500 Jobs an einen Drucker geschickt. Das ganze lief dann eine Zeitlang und aktuell liegen etwas über 35000 Jobs dort in der Mailqueue, Tendenz steigend. Erstes Ziel ist natürlich, den Prozess abzuschiessen und dafür zu sorgen, dass nicht noch mehr Jobs abgesetzt werden. Nichtsdestotrotz sind da halt die Jobs in der Mailqueue und sobald jemand den Drucker einschaltet, gehts los...

Wenn ich mit cancel oder lprm arbeite geht das zwar, aber dauert pro Job zwischen 10 und 60 Sekunden! So klappt das niemals.

Hat jemand einen Tip, wie ich die Mailqueue leer bekomme? Ich bin nicht mal so schlau zu wissen, wo die Queue überhaupt gespeichert ist...

[guennid]

Holzhammermethode: /var/spool/cups/ auf dem druckserver leeren und Maschine sicherheitshalber rebooten..

Es sollte auch über das webinterface von cups gehen. Aber bei 35 000 ...? Weiß nicht, ob man da sowas bedacht hat.

Grüße, Günther

[PatrickBaer]

Das Druckerinterface will nicht. Frag nicht wieso, ist ja nicht mein/unser System.

/var/spool/cups und /var/spool/lp hab ich geleert, mit lpstat bekomme ich aber immer noch die tausende aufgelistet...

[rendegast]

cancel -a [-x]
sollte doch alle Jobs löschen resp. abbrechen.
Scheint mir passabler als Verzeichnisse zu löschen.

lprm
akzeptiert doch mehrere job-ID als Argument.
Wieviele gleichzeitig?
Die job-ID könnten vielleicht per lpq oder lpstat ermittelt werden.

[guennid]

Scheint mir passabler als Verzeichnisse zu löschen.

Da habe ich mich wohl nicht klar genug ausgedrückt. Der Vorschlag war, das Verzeichnis zu leeren, also alle Dateien im Verzeichnis zu löschen. Das hat in den seltenen Fällen, in denen ich bei cups nicht weiter wusste, immer funktioniert. Wo ich unsicher bin, ist wann cups darauf reagiert. Eigentlich sollte es mit einem restart des cups-servers getan sein. Sicherheitshalber würde ich aber rebooten. Und das genannte Verzeichnis ist die Warteschlange. Wenn da nichts mehr drin steht, kann cups nichts mehr drucken. Es sei denn, cups benutzt ein anderes Warteschlangenverzeichnis.

Das Druckerinterface will nicht. Frag nicht wieso, ist ja nicht mein/unser System.
[...]
Ich bin nicht mal so schlau zu wissen, wo die Queue überhaupt gespeichert ist...

In dem Zusammenhang wären vielleicht weitere Infos zu diesem "System"/Netzwerk? erforderlich.

Grüße, Günther

[PatrickBaer]

Also, zuerst mal: Ich bin nicht der Systemadministrator des Eimers, sondern ein unschuldiger DBA, der zwischen den Feiertagen greifbar war. Insofern habe ich wirklich wenig wenig Ahnung. Alles was ich mit 100%iger Sicher sagen kann ist, dass da 35000 Druckjobs anstehen, ich den Eimer nicht einfach mal so durchtreten kann (weil x User drauf) und der Systemadministrator keinen Bock hat, ans Telefon zu gehen

Die Sachen mit cancel und lprm habe ich natürlich alle gemacht. Nur, wie oben geschrieben, dauert das ewig und drei Tage, weil auch cancel -a einen nach dem anderen abarbeitet.

[rendegast]

Ich habe mal meinen cups beschossen mit einfachen Jobs
'lp datei -d drucker'
("drucker" existiert nur in cups, postscript,
"datei" hat 42 Byte)

Bei 1000 davon bin ich an die Standard-Grenze 'MaxJobs 500' gestoßen.
-> 'MaxJobs 15000'

'cancel -a -x drucker'
1000 der jobs werden in 69 sec geloescht ~ 15 pro sec.

Bei

Code: Alles auswählen

seq 1 10100 | while read line; do lp datei -d drucker; done

gab es eine minutenlange Pause bei ~ 4700, dann nochmal bei ~ 8800.

Code: Alles auswählen

# lpq -a | wc -l
10100
# date; cancel -a -x drucker; date
Wed Jan  6 19:36:31 CET 2016
cancel: purge-jobs failed: Success
Wed Jan  6 19:37:31 CET 2016

# lpq -a | wc -l
lpq: Success
0

Nominell 160 pro Sekunde geloescht.
Aber verbleibend noch massenhaft Prozesse

• lpd
  foomatic-rip
  textopdf
  pdftopdf

weitere Minuten lang.
Dabei ist das System "ausgerastet" (unausgelasteter Doppelkern, 3 von 4GB frei/cache),
htop macht 100% auf seiner CPU mit mühseliger Bedienung,
pstree macht keine sinnvolle Ausgabe.

Code: Alles auswählen

# date ; lprm -P drucker $(lpstat | awk '{print $1}' | sed 's@^drucker-@@') ; date
Wed Jan  6 20:37:51 CET 2016
Wed Jan  6 20:44:58 CET 2016

Loescht 24/sec.

Code: Alles auswählen

# date ; lprm -P nimmer - ; date
Wed Jan  6 20:56:32 CET 2016
Wed Jan  6 20:57:02 CET 2016

schafft 330/sec.



Eventuell sind Deine 35.000 Jobs kein Unfall sondern ein DOS-Angriff?
cupsd scheint ja ein prima Ziel dafür.
Hier bekommt cupsd sicherheitshalber eine niedrige Prio resp. hohes nice ~17,
zuzüglich begrenztes MaxJobs.