SCO - Druckaufträge anhalten

Computer: Software & Programmierung UNIX & Linux
#1

Hallo,
ich habe öfter ein Problem mit meinen Druckern. (Unter SCO-UNIX 5.0)
Es kommt vor, daß Anwender versehentlich zu lange Listen drucken (10 000 Blatt statt 2 Blatt) und der Druck gestoppt werden muß.
Das mache ich dann mit…

# cancel drua1-1

richtig? Vermutlich nicht ganz, aber es funktioniert. :wink:
Leider stellt der Drucker seinen Dienst danach für einige Minuten bis Stunden ganz ein. Die einzige zuverlässige Maßnahme, den Drucker sofort wieder ‚aufzuwecken‘ ist: reboot. Das geht natürlich nicht so einfach. …

Kann mir jemand verraten, wie das ‚richtig‘ geht, den Drucker wieder zur Mitarbeit zu bewegen?

Gruß, Rainer

#2

Hallo !

Vorab: ich habe von SCO Unix keine Ahnung, evtl. geht das da anders…

cancel drua1-1

cancel sieht nach CUPS aus, und das wiederum setze ich auch unter Linux ein.
Da gibt es hier gelegentlich den Fehler, das cancel den Job zwar aus dem Scheduler löscht, den Prozess, der auf den Drucker zugreift ( „parallel“ irgendwo unter cups/backend) aber nicht beenden kann. Dadurch bleibt die Schnittstelle auf, und es kann kein neuer Druckjob gesendet werden.
Nach dem killen des parallel - Prozesses auf dem Server geht das Drucken hier wieder…

Alexander

#3

Hallo,

(Unter
SCO-UNIX 5.0)

Okay, weil es SCO ist, solltest Du dich an den Hersteller wenden (und - falls sie keine Antwort parat haben, einen Wechsel zu Linux ankündigen[1].

Es kommt vor, daß Anwender versehentlich zu lange Listen
drucken (10 000 Blatt statt 2 Blatt) und der Druck gestoppt
werden muß.
Das mache ich dann mit…

cancel drua1-1

richtig? Vermutlich nicht ganz, aber es funktioniert. :wink:
Leider stellt der Drucker seinen Dienst danach für einige
Minuten bis Stunden ganz ein.

Wie ist der Drucker denn angeschlossen? Was für eine Schnittstelle?

Die einzige zuverlässige
Maßnahme, den Drucker sofort wieder ‚aufzuwecken‘ ist: reboot.
Das geht natürlich nicht so einfach. …

Hast Du mal versucht, das Drucksystem (CUPS?) neu zu starten?

Gruß,

Sebastian

[1] Diese Vollidioten haben mir immernoch kein Angebot zu einer Linux-Lizenz geschickt. Vermutlich wird die Firma heute wieder unterhalsame Verrenungen machen um die nahende Pleite zu verklausulieren. Das heißt: Rainer, sieh zu, daß Du so schnell wie möglich einen Migrationsplan weg von SCO machst. Echt jetzt.

#4

Hallo Sebastian,

(Unter
SCO-UNIX 5.0)

Okay, weil es SCO ist, solltest Du dich an den Hersteller
wenden (und - falls sie keine Antwort parat haben, einen
Wechsel zu Linux ankündigen[1].

*g* zu alt! Dafür gibt’s keinen Support mehr. Die software läuft aber nur genau auf dieser Version von SCO-Unix.

Wie ist der Drucker denn angeschlossen? Was für eine
Schnittstelle?

Netzwerkdrucker. Wird über die IP-Adresse angesprochen, aber über die Mac-Adresse identifiziert.

Hast Du mal versucht, das Drucksystem (CUPS?) neu zu starten?

Nein, zu wenig Ahnung, das kann ich nicht. Experimentieren geht auch nicht.

[1] Diese Vollidioten haben mir immernoch kein Angebot zu
einer Linux-Lizenz geschickt. Vermutlich wird die Firma heute
wieder unterhalsame Verrenungen machen um die nahende Pleite
zu verklausulieren. Das heißt: Rainer, sieh zu, daß Du so
schnell wie möglich einen Migrationsplan weg von SCO machst.
Echt jetzt.

Das ist leider nicht möglich. Die Software ist an diese SCO-Version angepasst und läuft auf keinem anderen BS. Ändern oder anpassen ist unmöglich, selbst der Entwickler der Software sieht sich dazu außer Stande. Über einen Wechsel z.B. zu SAP wird seit Jahren nachgedacht. An der Entscheidung bin ich nicht beteiligt.

Gruß, Rainer

#5

Hallo alexander,

Vorab: ich habe von SCO Unix keine Ahnung, evtl. geht das da
anders…

schade. ;-(

cancel drua1-1

cancel sieht nach CUPS aus, und das wiederum setze ich auch
unter Linux ein.

Wer ist CUPS?

Da gibt es hier gelegentlich den Fehler, das cancel den Job
zwar aus dem Scheduler löscht, den Prozess, der auf den
Drucker zugreift ( „parallel“ irgendwo unter cups/backend)
aber nicht beenden kann. Dadurch bleibt die Schnittstelle auf,
und es kann kein neuer Druckjob gesendet werden.
Nach dem killen des parallel - Prozesses auf dem Server geht
das Drucken hier wieder…

OK, das ist ein Anhaltspunkt. Die Prozesse kann ich mir ja mal genauer ansehen. Ich fürchte aber, daß meine Kenntnisse nicht ausreichen werden, den entsprechenden Prozess zu finden. Hast Du einen Tipp, woran ich den erkennen kann? grep CUPS liefert keine Ergebnisse. … eventuell weil gerade nichts gedruckt wird? Ich probier das noch mal, wenn der wieder hängt. …

Danke, Gruß, Rainer

#6

Hallo !

cancel drua1-1

cancel sieht nach CUPS aus, und das wiederum setze ich auch
unter Linux ein.

Wer ist CUPS?

Common Unix Printing System

Da gibt es hier gelegentlich den Fehler, das cancel den Job
zwar aus dem Scheduler löscht, den Prozess, der auf den
Drucker zugreift ( „parallel“ irgendwo unter cups/backend)
aber nicht beenden kann. Dadurch bleibt die Schnittstelle auf,
und es kann kein neuer Druckjob gesendet werden.
Nach dem killen des parallel - Prozesses auf dem Server geht
das Drucken hier wieder…

OK, das ist ein Anhaltspunkt. Die Prozesse kann ich mir ja mal
genauer ansehen. Ich fürchte aber, daß meine Kenntnisse nicht
ausreichen werden, den entsprechenden Prozess zu finden. Hast
Du einen Tipp, woran ich den erkennen kann? grep CUPS liefert
keine Ergebnisse. … eventuell weil gerade nichts gedruckt
wird? Ich probier das noch mal, wenn der wieder hängt. …

Naja, hier heisst der „parallel“ (usb, serial, etc. gibt es auch), suchen nach dem Device des Druckers (/dev/lp0 ist es im Linux) in der Kommandozeile könnte auch helfen, da das als Parameter übergeben wird.
Unter Linux liegt das alles unter /usr/lib/cups/backend , mit der passenden Option zu ps sollte man den Pfad der Prozesse auch angezeigt bekommen…
Der Prozess läuft nur, wenn etwas geruckt wird (oder es hängt…).

Alexander

1 Like
#7

Über einen Wechsel z.B. zu SAP wird seit Jahren nachgedacht.

Das hieße ja, den Teufel mit dem Beelzebub auszutreiben…

An der Entscheidung bin ich nicht beteiligt.

Sei froh. Dann bist Du wenigstens nicht derjenige, der in fünf Jahren gefragt wird, warum seit vier Jahren teure SAP’ler quasi in eurer Firma wohnen und auch kein Ende absehbar ist.

SCNR,

Malte.

#8

Hallo Malte,

Über einen Wechsel z.B. zu SAP wird seit Jahren nachgedacht.

Das hieße ja, den Teufel mit dem Beelzebub auszutreiben…

*g* ja. Eventuell wird’s auch Infor o.ä., aber ob das besser ist? Kenn ich alles nicht. … Nur 'ne SAPDB lese ich schon mit VB aus (Server der Muttergesellschaft) und das geht recht gut.

An der Entscheidung bin ich nicht beteiligt.

Sei froh. Dann bist Du wenigstens nicht derjenige, der in fünf
Jahren gefragt wird, warum seit vier Jahren teure SAP’ler
quasi in eurer Firma wohnen und auch kein Ende absehbar ist.

Ach was. Schuld sind doch immer die, die nichts dafür können. :wink:

SCNR,

Kein Problem, ich find’s ja auch lustig.

Gruß, Rainer

#9

Hi,

Naja, hier heisst der „parallel“

OK, das kann hier nicht sein, weil parallel kein Drucker angeschlossen ist. Das sind alles Netzwerkdrucker. …

Unter Linux liegt das alles unter /usr/lib/cups/backend

Schade, den Pfad /usr/lib/cups gibt’s leider nicht. ;-(

, mit
der passenden Option zu ps sollte man den Pfad der Prozesse
auch angezeigt bekommen…

Ja, mit # ps -efa … kann ich mir alle Prozesse ansehen, das weiß ich. Leider verstehe ich nicht bei allen Prozessen, was die tun, da laufen ein paar hundert.
Bisher habe ich nur mit # ps -efa |grep ‚Domainname‘ nachgesehen, welche User angemeldet sind. Wenn ich vor habe, den rechner neu zu starten, müssen alle User abgemeldet sein, sonst wird meine Datenbank inkonsistent. Das ist zum Glück noch nicht passiert.

Der Prozess läuft nur, wenn etwas geruckt wird (oder es
hängt…).

OK, danke, beim nächsten mal, werde ich mir die Zeit nehmen und suchen. es ist halt nur dumm, daß dann der Drucker so lange steht und die Anwender schnell ungeduldig werden. Die habe ich wohl verwöhnt. :wink: Ausfälle sind nicht üblich und die Seltenen dauern nie länger als 10 Minuten. Der Sinn meiner Frage war, das noch weiter zu verbessern.

Danke für die Hilfe!

Gruß, Rainer