Hallo. Ich habe mal eine Verständnisfrage: Nehmen wir an, dass ich mit xcdroast brenne. xcdroast nutzt cdrecord. Angenommen, xcdroast oder XFree würde abstürzen (aus welchen "unnatürlichen" Gründen auch immer :-) ), dann müsste cdrecord doch trotzdem weiterbrennen, weil es im Hintergrund auf konsolenebene läuft, oder? D.h. die CD müsste trotzdem "gelingen"... thx & cu Dominik
Dominik Haumann wrote:
Nehmen wir an, dass ich mit xcdroast brenne. xcdroast nutzt cdrecord. Angenommen, xcdroast oder XFree würde abstürzen (aus welchen "unnatürlichen" Gründen auch immer :-) ), dann müsste cdrecord doch trotzdem weiterbrennen, weil es im Hintergrund auf konsolenebene läuft, oder? D.h. die CD müsste trotzdem "gelingen"...
Glaube ich nicht. Kannst Du so ausprobieren: Starte einen Prozes in einem Terminalfenster im Hintergrund: find / -name "*HAL9000*" & Mach dann das Fenster zu bzw. beende X mit Strg-Alt-Backspace Du wirst den find Prozess nicht mehr finden, weil er ein Kindprozess von xterm ist und das ist gekillt worden. Mit nohup find / -name "*HAL9000*" & läuft er weiter. Ciao, Ingo
On Sonntag, 9. September 2001 14:58 Dominik Haumann wrote:
Nehmen wir an, dass ich mit xcdroast brenne. xcdroast nutzt cdrecord. Angenommen, xcdroast oder XFree würde abstürzen (aus welchen "unnatürlichen" Gründen auch immer :-) ), dann müsste cdrecord doch trotzdem weiterbrennen, weil es im Hintergrund auf konsolenebene läuft, oder? D.h. die CD müsste trotzdem "gelingen"...
Nun, solange dein Brenner noch brennt und du kein KILL-Signal in irgendwelcher Weise auch immer gesendet hast, sollte die CD eigentlich korrekt gebrannt worden sein. Am besten sieht man das am Brenner selber (vg. der hat ne zweite Kontrollleuchte). Wenn da nämlich diese meist rote Lampe noch brennt, dann brennt der auch noch die CD. -- http://www.bbinternet.de
Am Sonntag, 9. September 2001 14:58 schrieb Dominik Haumann:
Nehmen wir an, dass ich mit xcdroast brenne. xcdroast nutzt cdrecord.
Richtig.
Angenommen, xcdroast oder XFree würde abstürzen (aus welchen "unnatürlichen" Gründen auch immer :-) ), dann müsste cdrecord doch trotzdem weiterbrennen, weil es im Hintergrund auf konsolenebene läuft, oder? D.h. die CD müsste trotzdem "gelingen"...
Nö, xcdroast startet cdrecord, wenn aber der elternprozess flöten geht, gehen auch die Kinder baden. Genau so wie alle aus einem xterm oder KDE Konsole gestarteten Programme weg sind, wenn Du die xterm/konsole beendest (läst sich wunderbar ausprobieren). -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de
Am Sonntag, 9. September 2001 18:12 schrieb Manfred Tremmel:
Am Sonntag, 9. September 2001 14:58 schrieb Dominik Haumann:
Nehmen wir an, dass ich mit xcdroast brenne. xcdroast nutzt cdrecord.
Richtig.
Angenommen, xcdroast oder XFree würde abstürzen (aus welchen "unnatürlichen" Gründen auch immer :-) ), dann müsste cdrecord doch trotzdem weiterbrennen, weil es im Hintergrund auf konsolenebene läuft, oder? D.h. die CD müsste trotzdem "gelingen"...
Nö, xcdroast startet cdrecord, wenn aber der elternprozess flöten geht, gehen auch die Kinder baden. Genau so wie alle aus einem xterm oder KDE Konsole gestarteten Programme weg sind, wenn Du die xterm/konsole beendest (läst sich wunderbar ausprobieren).
AFAIK ist das aber nur so, weil xterm, bzw die shell das Signal abfängt, und an seine Kinder weiterreicht, wenn DU nämlich von irgendeinem Prozeß aus mit fork() einen kindprozeß startest, und danach der Elternprozeß "stirbt", hast Du einen Waisen, und der landet beim Elternprozeß init.
* Manfred Gahr schrieb am 09.Sep.2001:
Am Sonntag, 9. September 2001 18:12 schrieb Manfred Tremmel:
Nö, xcdroast startet cdrecord, wenn aber der elternprozess flöten geht, gehen auch die Kinder baden.
Nö
Genau so wie alle aus einem xterm oder KDE Konsole gestarteten Programme weg sind, wenn Du die xterm/konsole beendest (läst sich wunderbar ausprobieren).
AFAIK ist das aber nur so, weil xterm, bzw die shell das Signal abfängt, und an seine Kinder weiterreicht,
Auch nicht ganz richtig. Was Du beschreibst sind Eingaben von CTRL-C und von ^@ (Wie immer man das auf einer deutschen Tastatur eingibt, natürlich sind nicht das Zeichen ^ und dann das Zeichen @ gemeint, sondern das ASCII-Zeichen Nul) Da wird das Signal SIGINT = Signal 2 bzw. das Signal SIGQUIT = Signal 3 an den Prozessen, die dem Terminal zugeordnet sind [1], die das Signal erhalten weitergeleitet. Wenn sich eine shell beendet, wird an allen Kindprozessen das Signal SIGHUP = Signal 1 weitergeleitet. Daraufhin beendet sich der Kindprozeß, wenn er Signal 1 nicht abfängt. Daher auch nohup ^^^ Damit wird Signal 1 abgefangen und verworfen.
wenn DU nämlich von irgendeinem Prozeß aus mit fork() einen kindprozeß startest, und danach der Elternprozeß "stirbt", hast Du einen Waisen, und der landet beim Elternprozeß init.
So ist es. [1] Damit ist aber nicht das kontrolierende Terminal gemeint, sonder AFAIK die Terminalgruppe. Bernd -- Homepages von deutschsprachigen Linux-Gurus: Kristian Köhntopp: http://www.koehntopp.de/kris/artikel/ Sven Guckes: http://www.math.fu-berlin.de/~guckes/sven Robin S Socha: http://socha.net/index2.html |Zufallssignatur 10
participants (6)
-
B.Brodesser＠t-online.de -
Bjoern Berg -
Dominik Haumann -
Ingo Wichmann -
M.A.N.E＠t-online.de -
Manfred Tremmel