Danke für Deine Antwort ich habe nun folgendes versucht: # netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID und das ist das Ergebnis [1] 2183 Can't grab 0.0.0.0:631 with bind [1]+ Exit 1 netcat -u -l -p 631 bash: kill: (2183) - Kein passender Prozess gefunden ich habe auch im Hintergrund keinen netcat laufen, daher ist mir auch nicht klar, wo das Problem liegen könnte Christian Boltz wrote:
Hallo Agata, hallo Leute,
zu Deinem CUPS-Problem weiß ich auf Anhieb nichts, nur soviel:
Am Sonntag, 5. Oktober 2003 12:22 schrieb Agata Góralczyk:
Auf den Versuch einen broadcastenden Server zu erreichen erhalte ich folgende Ausgabe: $ netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill \ $PID
^^^^
Der Backslash (und das Leerzeichen) sind zuviel.
Mir scheint, dass das Leerzeichen erst in der Mail aufgetaucht ist, sonst hätte es wohl funktioniert ;-)
Vermutlich hast Du also getestet mit ... ; kill $PID und damit das $-Zeichen maskiert.
Can't grab 0.0.0.0:631 with bind : Permission denied
Als root probiert?
Es könnte allerdings auch sein, dass ein bereits laufender netcat den Port belegt hat. Den Grund für diese Vermutung findest Du weiter unten.
[3] 2062
netcat geht also mit Job-ID [1] "3" in den Hintergrund
[2] Exit 1 netcat -u -l -p 631
Hier beendet sich gerade ein vorher gestarteter netcat mit Exitstatus 1 (also mit Fehler)
Blöde Frage: irgendwie vermisse ich Job-ID "1", läuft da vielleicht noch ein netcat im Hintergrund?
Prüf das mal nach per ps aux |grep "[n]etcat"
[3]+ Exit 1 netcat -u -l -p 631
Dein gerade gestarteter netcat (Job "3") beendet sich, ebenfalls mit Fehlern.
bash: kill: $PID: no such pid
^^^^
Die Auswirkung des Backslashes oben - an dieser Stelle sollte eigentlich eine Zahl stehen - und nicht der Name der Variable, die diese Zahl enthält.
Gruß
Christian Boltz
[1] Bitte daran denken: Die (bash-interne) Job-ID hat nichts mit der PID eines Prozesses zu tun!
-- Nicht weil die Dinge schwierig sind, wagen wir sie nicht, sondern weil wir sie nicht wagen, sind sie schwierig.