Hallo, Martin Schröder schrieb:

Am 20. Februar 2010 12:42 schrieb Thomas Michalka :

...

habe hier gerade einen Fall, den ich noch nicht erlebt habe: ein Programm lässt sich nicht einmal mit kill -KILL <process-id> abschießen.

http://de.wikipedia.org/wiki/Kill_%28Unix%29

Danke für den Hinweis. Ein Zitat aus dem Artikel: "Neben dem Signal SIGSTOP ist SIGKILL daher das einzige Signal, welches vom Programm nicht „abgefangen“ werden kann, um programmspezifische Aktionen durchzuführen. Die zwei Signale SIGKILL und SIGSTOP werden demnach nur von dem Kernel „gesehen“ und bieten damit in jedem Fall zuverlässige Wege, einen Prozess zu kontrollieren." Tja, so zuverlässig scheint das nicht zu sein, denn wieso konnte ich den mount-Prozess nicht 'killen'?

...

Darf es so etwas geben?

Darf es eigentlich nicht, zumindest laut Wikipedia-Artikel nicht, aber gibt es eben dennoch.

Ich habe dadurch gerade eine Systemlast von 13 -

...

14. Ein Wunder (?), dass ich diese Mail schreiben kann.

http://de.wikipedia.org/wiki/Load#Der_Load_Average_auf_Unix-Systemen

Danke auch hierfür. Der ist ja etwas länger und komplizierter, so dass ich mal eine frei Stunde für das Studium investieren muss.

Ganz schlechtes OS, wenn es bei einer Load von 14 unbedienbar ist.

Kommt darauf an ... Das Betriebssystem kann da nur bedingt was dafür, sondern eher das Hardware-Design, wie ich durch Vergleich zweier Maschinen weiß. Das Linux auf meiner relativ modernen aktuellen Maschine war ja noch gut bedienbar, wohl deshalb, weil ich nicht mehr Festplattenaktivitäten, wodurch die hohe Last kam, verursacht habe, und die CPU bei Festplattenaktivitäten kaum beteiligt ist. Auf einem anderen System hatte ich da früher schon negativere Erfahrungen gemacht, weil hier die CPU viel mehr in Aktivitäten der Festplatten involviert ist. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, Am Son, 21 Feb 2010, Thomas Hertweck schrieb:

On 21/02/10 11:17, Thomas Michalka wrote:

...

[...] Tja, so zuverlässig scheint das nicht zu sein, denn wieso konnte ich den mount-Prozess nicht 'killen'?

Weil Du Prozesse im Status D (uninterruptible sleep) nicht killen kannst.

... denn die laufen ja auch gar nicht (mehr), sondern wurden vom Kernel schlafen gelegt, weil auf Daten (aus dem Netz/von Platte) gewartet werden muß. Kurz: Prozesse die im Status 'D' schlafen kann man killen -- allerdings wirkt sich das _erst_ aus, wenn die Prozesse aus diesem Status wieder rauskommen / aufwachen. Was durchaus mal länger dauern kann. Da hilft nur auf den Timeout warten oder, falls die HW hängt, ein Reboot. Bei NFS hilft übrigens meist NFS+ggfs. Portmap am Server zu stoppen und neu zu starten, ansonsten das gleiche lokal (bzw. erst am Server alle stoppen, lokal stoppen, server starten, lokal starten)... Server NFS-restarts überleben übrigens Kopieraktionen per mc (die überleben sogar nen reboot des servers!)... NFS ist meiner Erfahrung nach robuster als man allgemein denkt, nur erfordert es halt ggfs. mal nen restart des Server- und/oder Client-NFS/Portmap Krams. Bei ersterem IIRC ohne "Neustart" des Transfers. BTDT (bei >>200 MB Dateien, alles "heil" angekommen)... Und das sogar zw. lokal Kernel 2.4.x und am Server 2.6.x. Bei lokalen NFS-restarts bricht mc IIRC den Transfer ab, aber mc macht ja "copy && rm". Muß man die Datei halt nochmal rüberschieben ... -dnh -- Wir brauchen dem CIA keine falschen Beweismittel liefern, wir _haben_ Massenvernichtungswaffen in Deutschland. Schau mal ins Fernsehen, ha, Gute Zeiten Schlechte Zeiten, Superstars, Lenßen und Partner, die ganzen Ferrero-Küßchen Wixer... -- Michael Mittermaier, "Paranoid" -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Nachdem ich nun diese Anfrage schon vor einigen Tagen bei easy-linux gestellt habe (...um dort noch einige Ubuntu Leute zu erreichen ) stelle ich sie nun im Opensuse-Forum. ...habe mir einen Terratec Cinergy T2 RC-Stick (usb-dvb-t) gekauft. Der T2 macht laut HKL-Liste keine Probleme; anders beim T2 RC - hier liegt neue Hardware vor. Hat jemand unter Opensuse den Stick schon zum laufen gebracht?? Unter Ubuntu hat es mittlerweile geklappt !! siehe auch : http://forum.ubuntuusers.de/topic/probleme-beim-installieren-terratec-cinerg... t/3 Meinerseits habe ich auch auf meinem Laptop folgendes gemacht: hg clone http://linuxtv.org/hg/v4l-dvb wget http://jusst.de/manu/fw/AFA/dvb-usb-af9015.fw_a-link mv dvb-usb-af9015.fw_a-link /lib/firmware/dvb-usb-af9015.fw unter root und die Dateien sowie beschrieben kopiert. make und make install laufen ohne Probleme: ------------------------------------------------------------------------------------------------------------------- laptop1:/home/ehlert/v4l-dvb # make install make -C /home/ehlert/v4l-dvb/v4l install make[1]: Entering directory `/home/ehlert/v4l-dvb/v4l' Removing obsolete files from /lib/modules/2.6.31.12-0.1- desktop/kernel/drivers/media/video: Removing obsolete files from /lib/modules/2.6.31.12-0.1- desktop/kernel/drivers/media/dvb/cinergyT2: Removing obsolete files from /lib/modules/2.6.31.12-0.1- desktop/kernel/drivers/media/common: Removing obsolete files from /lib/modules/2.6.31.12-0.1- desktop/kernel/drivers/media/dvb/frontends: Installing kernel modules under /lib/modules/2.6.31.12-0.1- desktop/kernel/drivers/media/: video/gspca/m5602/: gspca_m5602.ko dvb/dvb-usb/: dvb-usb-dtv5100.ko dvb-usb-opera.ko dvb-usb-cxusb.ko dvb-usb-vp7045.ko dvb-usb-af9005-remote.ko dvb-usb-ttusb2.ko dvb-usb-af9015.ko dvb-usb-dib0700.ko dvb-usb-a800.ko dvb-usb-gp8psk.ko dvb-usb-dibusb-common.ko dvb-usb-au6610.ko dvb-usb-digitv.ko dvb-usb.ko dvb-usb-dibusb-mc.ko dvb-usb-af9005.ko dvb-usb-nova-t-usb2.ko dvb-usb-friio.ko dvb-usb-ce6230.ko dvb-usb-dtt200u.ko dvb-usb-cinergyT2.ko dvb-usb-vp702x.ko dvb-usb-umt-010.ko dvb-usb-anysee.ko dvb-usb-dibusb-mb.ko dvb-usb-dw2102.ko dvb-usb-gl861.ko dvb-usb-ec168.ko dvb-usb-m920x.ko video/saa7164/: saa7164.ko video/zoran/: videocodec.ko zr36050.ko zr36016.ko zr36060.ko zr36067.ko video/cx18/: cx18.ko cx18-alsa.ko video/cpia2/: cpia2.ko dvb/b2c2/: b2c2-flexcop-pci.ko b2c2-flexcop.ko b2c2-flexcop-usb.ko video/ivtv/: ivtvfb.ko ivtv.ko dvb/mantis/: mantis_core.ko mantis.ko hopper.ko video/hdpvr/: hdpvr.ko common/tuners/: tuner-xc2028.ko mt2060.ko tda9887.ko mt2131.ko mc44s803.ko qt1010.ko max2165.ko mt20xx.ko tda827x.ko tda18271.ko xc5000.ko mxl5007t.ko tea5761.ko tuner-types.ko tda8290.ko tuner-simple.ko mt2266.ko tea5767.ko mxl5005s.ko video/sn9c102/: sn9c102.ko dvb/dvb-core/: dvb-core.ko video/: videobuf-dma-contig.ko vpx3220.ko videobuf-dma-sg.ko bt856.ko upd64083.ko v4l2-compat-ioctl32.ko stradis.ko videobuf-core.ko ths7303.ko tda9840.ko saa7191.ko cx2341x.ko wm8775.ko meye.ko adv7180.ko w9968cf.ko rj54n1cb0c.ko saa7185.ko tuner.ko mt9t031.ko zr364xx.ko ks0127.ko stv680.ko videobuf-dvb.ko tvaudio.ko tea6420.ko bt866.ko cafe_ccic.ko mt9v011.ko saa5246a.ko msp3400.ko tvp514x.ko tcm825x.ko soc_camera.ko wm8739.ko stkwebcam.ko saa5249.ko cpia_pp.ko soc_mediabus.ko tda7432.ko w9966.ko ir-kbd-i2c.ko mt9m001.ko upd64031a.ko ov511.ko tea6415c.ko dabusb.ko bt819.ko cpia_usb.ko videodev.ko mxb.ko tda9875.ko adv7175.ko vivi.ko soc_camera_platform.ko adv7343.ko cs53l32a.ko s2255drv.ko btcx-risc.ko se401.ko saa7110.ko saa7115.ko saa6588.ko v4l2-common.ko hexium_gemini.ko hexium_orion.ko tw9910.ko tvp5150.ko mt9m111.ko vp27smpx.ko adv7170.ko ov772x.ko ov7670.ko saa7127.ko m52790.ko ov9640.ko mt9v022.ko v4l1-compat.ko videobuf-vmalloc.ko v4l2-int-device.ko c-qcam.ko tveeprom.ko cs5345.ko saa717x.ko cpia.ko tlv320aic23b.ko bw-qcam.ko mt9t112.ko video/cx23885/: cx23885.ko dvb/firewire/: firedtv.ko dvb/bt8xx/: dst_ca.ko dvb-bt8xx.ko bt878.ko dst.ko dvb/siano/: smssdio.ko smsdvb.ko smsusb.ko smsmdtv.ko video/cx25840/: cx25840.ko dvb/ttusb-dec/: ttusbdecfe.ko ttusb_dec.ko dvb/ngene/: ngene.ko dvb/dm1105/: dm1105.ko video/cx231xx/: cx231xx.ko cx231xx-dvb.ko cx231xx-alsa.ko video/saa7134/: saa6752hs.ko saa7134-empress.ko saa7134-alsa.ko saa7134-dvb.ko saa7134.ko dvb/ttpci/: dvb-ttpci.ko budget-patch.ko ttpci-eeprom.ko budget-av.ko budget.ko budget-core.ko budget-ci.ko video/et61x251/: et61x251.ko video/gspca/gl860/: gspca_gl860.ko IR/: ir-core.ko ir-common.ko radio/si470x/: radio-usb-si470x.ko dvb/frontends/: nxt6000.ko dib7000m.ko dib0090.ko drx397xD.ko s5h1411.ko tda665x.ko dib8000.ko nxt200x.ko s921.ko s5h1409.ko atbm8830.ko dib3000mb.ko ec100.ko lgs8gl5.ko dib3000mc.ko stv0900.ko sp8870.ko tda8083.ko stv0297.ko tda10086.ko zl10353.ko mb86a16.ko lgs8gxx.ko stv0299.ko dvb-pll.ko cx22702.ko lgdt3304.ko tda8261.ko tua6100.ko bcm3510.ko stb0899.ko or51211.ko cx24113.ko tda826x.ko af9013.ko au8522.ko si21xx.ko s5h1420.ko stv090x.ko stv0288.ko mt352.ko zl10039.ko isl6405.ko sp887x.ko dibx000_common.ko isl6421.ko mt312.ko or51132.ko tda1004x.ko stv6110.ko itd1000.ko stv6110x.ko zl10036.ko lgdt3305.ko dib7000p.ko l64781.ko ves1x93.ko stb6100.ko ves1820.ko dib0070.ko cx22700.ko cx24110.ko dvb_dummy_fe.ko lgdt330x.ko cx24123.ko lnbp21.ko stb6000.ko isl6423.ko tda10023.ko cx24116.ko tda10021.ko tda10048.ko ds3000.ko video/bt8xx/: bttv.ko video/cx88/: cx8802.ko cx8800.ko cx88-blackbird.ko cx88-alsa.ko cx88xx.ko cx88-vp3054-i2c.ko cx88-dvb.ko video/gspca/: gspca_stk014.ko gspca_spca501.ko gspca_spca500.ko gspca_mars.ko gspca_stv0680.ko gspca_sunplus.ko gspca_vc032x.ko gspca_benq.ko gspca_spca505.ko gspca_sn9c20x.ko gspca_zc3xx.ko gspca_sq905c.ko gspca_sonixb.ko gspca_etoms.ko gspca_pac7302.ko gspca_pac207.ko gspca_ov534_9.ko gspca_spca508.ko gspca_sq905.ko gspca_sn9c2028.ko gspca_t613.ko gspca_spca561.ko gspca_ov534.ko gspca_tv8532.ko gspca_jeilinj.ko gspca_spca506.ko gspca_sonixj.ko gspca_main.ko gspca_cpia1.ko gspca_conex.ko gspca_mr97310a.ko gspca_pac7311.ko gspca_ov519.ko gspca_finepix.ko dvb/pluto2/: pluto2.ko video/usbvideo/: ibmcam.ko usbvideo.ko vicam.ko ultracam.ko konicawc.ko quickcam_messenger.ko video/usbvision/: usbvision.ko common/: saa7146_vv.ko saa7146.ko video/gspca/stv06xx/: gspca_stv06xx.ko video/em28xx/: em28xx-dvb.ko em28xx-alsa.ko em28xx.ko radio/: dsbr100.ko radio-maestro.ko si4713-i2c.ko tef6862.ko radio-maxiradio.ko radio-tea5764.ko radio-si4713.ko radio-gemtek-pci.ko radio-mr800.ko video/pvrusb2/: pvrusb2.ko dvb/pt1/: earth-pt1.ko video/uvc/: uvcvideo.ko dvb/ttusb-budget/: dvb-ttusb-budget.ko video/pwc/: pwc.ko video/ovcamchip/: ovcamchip.ko video/zc0301/: zc0301.ko video/au0828/: au0828.ko /sbin/depmod -a 2.6.31.12-0.1-desktop make -C firmware install make[2]: Entering directory `/home/ehlert/v4l-dvb/v4l/firmware' Installing firmwares at /lib/firmware: vicam/firmware.fw dabusb/firmware.fw dabusb/bitstream.bin ttusb-budget/dspbootcode.bin cpia2/s tv0672_vp4.bin av7110/bootcode.bin make[2]: Leaving directory `/home/ehlert/v4l-dvb/v4l/firmware' make[1]: Leaving directory `/home/ehlert/v4l-dvb/v4l' laptop1:/home/ehlert/v4l-dvb # ------------------------------------------------------------------------------------------------------------------- dann ein: modprobe dvb-usb-af9015 undlaptop1:/home/ehlert # dmesg | grep dvb [ 210.620082] usbcore: registered new interface driver dvb_usb_af9015 aber tail -f /var/log/messages Feb 18 18:53:07 laptop1 kernel: [ 3959.838874] usbcore: registered new interface driver dvb_usb_af9015 Feb 18 18:53:18 laptop1 kernel: [ 3970.149037] usb 1-3: new high speed USB device using ehci_hcd and address 8 Feb 18 18:53:18 laptop1 kernel: [ 3970.268019] usb 1-3: New USB device found, idVendor=0ccd, idProduct=0097 Feb 18 18:53:18 laptop1 kernel: [ 3970.268028] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Feb 18 18:53:18 laptop1 kernel: [ 3970.268033] usb 1-3: Product: USB2.0 DVB-T TV Stick Feb 18 18:53:18 laptop1 kernel: [ 3970.268038] usb 1-3: Manufacturer: NEWMI Feb 18 18:53:18 laptop1 kernel: [ 3970.268042] usb 1-3: SerialNumber: 010101010600001 Feb 18 18:53:18 laptop1 kernel: [ 3970.268161] usb 1-3: configuration #1 chosen from 1 choicer Feb 18 18:53:18 laptop1 kernel: [ 3970.274682] input: NEWMI USB2.0 DVB-T TV Stick as /devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3:1.1/input/input17 Feb 18 18:53:18 laptop1 kernel: [ 3970.274799] generic-usb 0003:0CCD:0097.0008: input,hidraw0: USB HID v1.01 Keyboard [NEWMI USB2.0 DVB-T TV Stick] on usb-0000:00:1a.7-3/input1 zeigt das kein Treiber vorhanden ist. hat jemand eine Idee oder weiß etwas über diesen Treiber Grüsse Ehlert Ruprecht -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Montag 22 Februar 2010 21:17:39 schrieb Thomas Hertweck:

On 22/02/10 13:56, Ehlert Ruprecht wrote:

...

Nachdem ich nun diese Anfrage schon vor einigen Tagen bei easy-linux gestellt habe (...um dort noch einige Ubuntu Leute zu erreichen ) stelle ich sie nun im Opensuse-Forum. [...]

Dann starte bitte einen neuen Thread und antworte nicht im Thread "kill -KILL <process-id> funktioniert nicht", in dem Du das Subject aenderst. Deine Anfrage taucht nun in voellig falschem Kontext auf bei jedem, der eine Thread-Ansicht nutzt.

Thomas

sorry, mach ich - ich mir "verrutscht". Ehlert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, Emil Stephan schrieb:

Am Saturday 20 February 2010 12:42:18 schrieb Thomas Michalka:

...

-o remount

Hallo Thomas, ein normaler mount setzt voraus, dass das Dateisystem nicht gemountet ist. Bei der Option -o remount ist es genau umgekehrt. Deshalb ja remount.

Ja klar. Ich schrieb doch: [...] den Befehl mount -o remount,rw /mountpoint ausführt. Eigentlich müsste mount dann ausgeben, dass das Dateisystem bereits gemountet ist, und das aufrufende Skript sollte sich daraufhin beenden. Ich wollte wissen, wie es sein konnte, dass es diese Fehlermeldung nicht gab, sondern der mount-Prozess plötzlich als Kindprozess von init weiterlief, obwohl er vorher der Kindprozess einer Shell war. Aktuell ausprobiert: $> mount [...] /dev/sda4 on /backup/notebook type ext3 (rw,noexec,nosuid,nodev,data=journal,acl,user_xattr) $> mount /backup/notebook mount: /dev/sda4 ist bereits eingehängt oder /backup/notebook wird gerade benutzt mount: Laut mtab ist /dev/sda4 schon auf /backup/notebook eingehängt $> mount -o remount,rw /backup/notebook $> Wenn man also ein bereits schreibbar gemountetes Dateisystem (irrtümlich) schreibbar remounten will, ^^ !! dann passiert normalerweise gar nichts. Nicht mal ein Hinweis, wie im obigen Versuch. Es sollte also im Gegensatz zu meiner ursprünglichen Meinung gar keinen Fehler im Skript geben. Jedoch bleibt unklar, warum sich der Mount-Prozess von der bash als ursprünglichem Elternprozess abgekoppelt hat. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, Emil Stephan schrieb:

Am Sunday 21 February 2010 11:56:12 schrieb Thomas Michalka:

...

[...]

[...] den Befehl mount -o remount,rw /mountpoint ausführt. Eigentlich müsste mount dann ausgeben, dass das Dateisystem bereits gemountet ist, und das aufrufende Skript sollte sich daraufhin beenden.

Hallo Thomas, mount gibt nichts aus, weil das zu Erreichende schon gegeben ist.

... was ich weiter unten nach Ausprobieren genau so beschrieben habe.

...

Ich wollte wissen, wie es sein konnte, dass es diese Fehlermeldung nicht gab, sondern der mount-Prozess plötzlich als Kindprozess von init weiterlief, obwohl er vorher der Kindprozess einer Shell war.

Die Shell hat sich beendet oder ist beendet worden. Damit verliert der mount-Prozess seinen Vater-Prozess. Ein Prozess, der seines Vater-Prozesses verlustig wird,

Aha, und unter welchen (besonderen) Umständen kann ein Prozess seines Vaters verlustig werden? Ich dachte immer, dass das Sterben eines Vaterprozesses i.d.R. das Sterben aller Kindprozesse nach sich zieht (ausser der Programmierer hat dagegen vorgesorgt)?

bekommt automatisch init als Vater-Prozess. Irgendeiner muss ja den Return-Status einsammeln.

Das wäre als Konsequenz einleuchtend. Aber so einfach ist es nicht, denke ich. Wann immer ich heute das (fast) gleiche Experiment in einem Terminal wiederhole, zeigt sich ein anderes Verhalten: jeder (längerlaufende; ein paar Sekunden reichen schon) Kind-Prozess stirbt, sobald ich seinen Elternprozess, also die bash beende. Sonst hätte ja nohup keinen Sinn.

...

Aktuell ausprobiert:

$> mount [...] /dev/sda4 on /backup/notebook type ext3 (rw,noexec,nosuid,nodev,data=journal,acl,user_xattr)

$> mount /backup/notebook mount: /dev/sda4 ist bereits eingehängt oder /backup/notebook wird gerade benutzt mount: Laut mtab ist /dev/sda4 schon auf /backup/notebook eingehängt

$> mount -o remount,rw /backup/notebook $>

Wenn man also ein bereits schreibbar gemountetes Dateisystem (irrtümlich) schreibbar remounten will, ^^ !! dann passiert normalerweise gar nichts. Nicht mal ein Hinweis, wie im obigen Versuch. Es sollte also im Gegensatz zu meiner ursprünglichen Meinung gar keinen Fehler im Skript geben.

Jedoch bleibt unklar, warum sich der Mount-Prozess von der bash als ursprünglichem Elternprozess abgekoppelt hat.

Gruß, Tom

Hast Du das Skript mal im Debug-Modus ausgeführt (sh -x)? Vielleicht ist das mount-Kommando gar nicht die Ursache für den Fehler im Skript.

Macht ja keinen Sinn so, denn den besonderen Umstand, dass bereits ein anderes Skript lief, das das Dateisystem ebenfalls schreibbar gemountet hatte, müsste ich wieder herstellen (s.u.).

Aus irgendeinem Grund verabschiedet sich das Skript,

Nicht aus "irgendeinem" Grund, ich habe es mit Strg-C (SIGINT) abgebrochen, wie Du in meinem urspr. Posting nachlesen kannst. Aber so einfach kann ich das nicht mehr nachstellen, denn mount läuft ja immer nur ultrakurz. Nur wenn es gelänge, diese verhaspelte Situation wiederherzustellen, als dasselbe Skript schon einmal lief und das Dateisystem bereits gemountet war, dann ... ja dann hätte ich dieselbe Situation reproduziert. Ich probiere das die Tage mal aus und poste das Ergebnis hier. Früher geht's leider nicht, denn heute Abend muss ich mit meinem Rechner umziehen. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, Joerg Thuemmler schrieb:

Thomas Michalka schrieb:

...

Hallo,

Emil Stephan schrieb:

...

Am Sunday 21 February 2010 11:56:12 schrieb Thomas Michalka:

...

[...]

...

[...]

Hi,

ein bei mir schon reproduzierbar aufgetretenes Beispiel (allerdings nich growisofs von Suse 8.1) ist ein Brennerabsturz durch Schreibfehler, wohl wg. defektem Medium. Growisofs rödelt und bricht nicht ab (weiß nicht ob da ein Timeout hätte kommen müssen). Mit KILL das Steuerscript abgeschossen - schon befindet sich der Schreibprozeß im Status "D", in diesem Falle ohne allzuviel Systemlast.

Genau das war ja bei mir anders. Kein Status D und hohe Systemlast. Aber welche Mechanismen führen zu dem einen und zu dem anderen, in beiden Fällen nichtnormalen Verhalten?

[...]

Jedenfalls sterben "D"-Prozesse nicht, wenn der Vaterprozeß stirbt, sie heißen auch passenderweise "Zombie" ;-)

Stellt sich bloß die Frage, warum der Kernel Zombies nicht nach einer Weile aus der Prozesstabelle entfernt, recht nützlich sind sie ja wohl nicht mehr, oder? Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, David Haller schrieb:

Hallo,

Am Mon, 22 Feb 2010, Thomas Michalka schrieb:

...

...

Jedenfalls sterben "D"-Prozesse nicht, wenn der Vaterprozeß stirbt, sie heißen auch passenderweise "Zombie" ;-) Stellt sich bloß die Frage, warum der Kernel Zombies nicht nach einer Weile aus der Prozesstabelle entfernt, recht nützlich sind sie ja wohl nicht mehr, oder?

Das sind keine Zombies. Die sind "Deadlocked" im Status IO-Wait (oder so).

Vermute mal: "Deadlocked" == "Uninterruptible Sleep" ?

Jedenfalls: wenn ich z.B. auf dem Server mal eben den nfsserver stoppe, dann landet ein cp, das grad von/auf den Server schiebt im Status D. Bis zum NFS-Timeout. Starte ich vorher den nfsserver wieder, wird unbeeindruckt weiterkopiert. Der Prozess läuft und lebt noch, aber ist halt in einem Wartezustand blockiert.

Aha - und ich habe das Skript, das 'mount -o remount,rw /<mpt>' aufrief, im Terminal mit STRG-C abgebrochen. Der mount-Prozess lief weiter, stets lasterzeugend das Mounten versuchend, was aber nichts half, weil das FS ja schon rw gemountet war. Erst nach einer geraumen Weile hat wohl ein Timeout für ein Ende des 'Spuks' gesorgt. Warum er aber weiterlief, obwohl der Elternprozess abgebrochen wurde, verstehe ich nachwievor nicht. Ausserdem habe ich noch nicht verstanden, warum ich den Deadlocked Prozess nicht mit kill -KILL <ID> abschießen konnte. Geht das bei solchen Prozessen im IO-Wait-Zustand auch nicht?

Zombies sind hingegen schon komplett tot und existieren ausschließlich noch als Einträge in der Prozesstabellen. Und der bleibt erhalten, bis der "Vaterprozess" (i.d.R. wird das 'init') den Exitstatus abholt. Das erklärt auch gleich, warum ein 'kill -9' nicht funktioniert. Der Zombie ist schon tot.

Dass man Zombies nicht töten kann, leuchtet ein. Dass diese nichts mit den D-Prozessen von oben zu tun haben, sieht man aber auch an der Statusausgabe von ps: für Zombies steht da sinnigerweise ein 'Z' (und dahinter ein '<defunct>').

Da hilft schlicht nur warten (sinnvoll) oder ein Reboot (nicht nötig). Ich beobachte hier recht regelmäßig z.B. cron-Zombies, die nach recht kurzer Zeit dann auch entsorgt werden.

Bei mir gibt es auch gerade einen Zombie, der als Kindprozess eines Epiphany noch herumlungert; der müsste entsorgt werden, wenn der Epiphany beendet wird -- Bingo! :-) Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org