Hozzászólások
-
Bejegyzés
-
Mi az, hogy „sérülten érkezik meg”? Hiányos? Változott? …
(csak vakon: a mime-type OK a csatolásban?)
Szerk: Szerintem vegyél valami kisméretű csatolmányt, azután küldd el a teszteledő környezetből, és küldd el ugyanoda a saját „normál” leveleződből is UGYANODA, majd hasonlítsd össze őket. Esetleg már „kimenetkor” tárold le mindkét esetben az adatforgalmat.
Mi az, hogy „sérülten érkezik meg”? Hiányos? Változott? …
(csak vakon: a mime-type OK a csatolásban?)
Szerk: Szerintem vegyél valami kisméretű csatolmányt, azután küldd el a teszteledő környezetből, és küldd el ugyanoda a saját „normál” leveleződből is UGYANODA, majd hasonlítsd össze őket. Esetleg már „kimenetkor” tárold le mindkét esetben az adatforgalmat.
Quote:Az amire te gondolsz, az a többszállas rendszer rémálma, amikor is az apukának nincs lehetősége (pl.: egy ilyen rosszul kiadott SIGKILL szignál, vagy egy bármilyen baleset után) a gyermekeit rendesen kiírtani és a deallokácó után megszakad a folyamat. :))
Ne ebben az esetben hiába is adsz ki egy SIGKILL szignált, amikor a process nem létezik egy élőholt… nem lehet megölni, mert már halott. Nos erre való a SIGCHLD szignál.
Nem csak ölni, ölni kell mindenáron… lehet egy csomó mindent csinálni. 🙂Egy szoftver végtelen ciklusú programot bárhol megölsz, parentben is meg childben is.
A megölhetetlen zombik esetében gyakorlatilag minden esetben egy kernel módú erőforrás allokáció áll, ahol a kernelmodul nem kezeli (általában programozási hiba miatt) a userprocess signaljait; nem szabadítja fel a „blokkolást”. A SIGCHLD-vel meg „szép” killekkel max a parent sem múlik el addig. Ha a kernelprocess valamiért végtelenségig hajlamos várni egy „elvileg biztosan bekövetkező” 😉 eseményre, no akkor van ilyen. De ezt semmivel sem lövöd ki. (BSD unix alatt, sok évvel ezelőtt sikerült ilyet programoznom 🙁 ) AZ AT&T unix streams driverstrukturája kiküszöböli ezt, ezzel viszont nem találkoztam linux alatt. Ugyanis szétválasztja a user space és kernel modú erőforrásfoglalásokat. (A user process eltávolítható, persze egy rosszul megírt kernelmodul attól még várakozhat a végtelenségig, aminek eredményeképpen az általa kezelt eszközt ismét csak reboot után tudod megszólítani) (Igaz, az utóbbi években nem írtam drivert)Egyébként a kikerülhetetlen újraindítás „szép” példája volt néhány éve (nem emlékszem, hogy SuSE-m vagy debianom volt-e akkor), amikor is a xsane és a gimp akadt össze, ha (akkor és abban a releaseben) rossz sorrendben installáltad őket. Mihelyt megpróbáltál scannelni, „Szó bennszakad, hang fennakad, Lehellet megszegik…” és a ps már egy [defunc] xsane-t mutat. kilőni nem lehet, X restart sem segít, csak a reboot. Akkoriban a google az xsane+gimp keresésre ezt a kóhibát sorolta az első öt helyen legalább…
A preemptive multitaskingnak itt annyi a jelentősége, hogy legalább szépen lehet újraindítani a gépet, mert akkoriban a win98 (cooperative multitasking) hasonló esetben állt, mint a farok a lakodalomban.
Quote:Az amire te gondolsz, az a többszállas rendszer rémálma, amikor is az apukának nincs lehetősége (pl.: egy ilyen rosszul kiadott SIGKILL szignál, vagy egy bármilyen baleset után) a gyermekeit rendesen kiírtani és a deallokácó után megszakad a folyamat. :))
Ne ebben az esetben hiába is adsz ki egy SIGKILL szignált, amikor a process nem létezik egy élőholt… nem lehet megölni, mert már halott. Nos erre való a SIGCHLD szignál.
Nem csak ölni, ölni kell mindenáron… lehet egy csomó mindent csinálni. 🙂Egy szoftver végtelen ciklusú programot bárhol megölsz, parentben is meg childben is.
A megölhetetlen zombik esetében gyakorlatilag minden esetben egy kernel módú erőforrás allokáció áll, ahol a kernelmodul nem kezeli (általában programozási hiba miatt) a userprocess signaljait; nem szabadítja fel a „blokkolást”. A SIGCHLD-vel meg „szép” killekkel max a parent sem múlik el addig. Ha a kernelprocess valamiért végtelenségig hajlamos várni egy „elvileg biztosan bekövetkező” 😉 eseményre, no akkor van ilyen. De ezt semmivel sem lövöd ki. (BSD unix alatt, sok évvel ezelőtt sikerült ilyet programoznom 🙁 ) AZ AT&T unix streams driverstrukturája kiküszöböli ezt, ezzel viszont nem találkoztam linux alatt. Ugyanis szétválasztja a user space és kernel modú erőforrásfoglalásokat. (A user process eltávolítható, persze egy rosszul megírt kernelmodul attól még várakozhat a végtelenségig, aminek eredményeképpen az általa kezelt eszközt ismét csak reboot után tudod megszólítani) (Igaz, az utóbbi években nem írtam drivert)Egyébként a kikerülhetetlen újraindítás „szép” példája volt néhány éve (nem emlékszem, hogy SuSE-m vagy debianom volt-e akkor), amikor is a xsane és a gimp akadt össze, ha (akkor és abban a releaseben) rossz sorrendben installáltad őket. Mihelyt megpróbáltál scannelni, „Szó bennszakad, hang fennakad, Lehellet megszegik…” és a ps már egy [defunc] xsane-t mutat. kilőni nem lehet, X restart sem segít, csak a reboot. Akkoriban a google az xsane+gimp keresésre ezt a kóhibát sorolta az első öt helyen legalább…
A preemptive multitaskingnak itt annyi a jelentősége, hogy legalább szépen lehet újraindítani a gépet, mert akkoriban a win98 (cooperative multitasking) hasonló esetben állt, mint a farok a lakodalomban.
strapal wrote:Mondjuk nem biztos hogy jó megoldás, nem is próbáltam sose, de a CD-meghajtókon szokott lenni egy kis lyuk, amibe ha valami pöcköt bedugsz, akkor kinyílik a tálca.Ezt bekapcsolt gépnél nem szívesen tenném, ha meg úgyis kikapcsolod, akkor a reboot is segít. (99.99%) Ez inkább a totálhalott driveok meg a „kiszereltem, de bennefelejtettem” esetére való.
strapal wrote:Mondjuk nem biztos hogy jó megoldás, nem is próbáltam sose, de a CD-meghajtókon szokott lenni egy kis lyuk, amibe ha valami pöcköt bedugsz, akkor kinyílik a tálca.Ezt bekapcsolt gépnél nem szívesen tenném, ha meg úgyis kikapcsolod, akkor a reboot is segít. (99.99%) Ez inkább a totálhalott driveok meg a „kiszereltem, de bennefelejtettem” esetére való.
Jobbik eset: Valószínüleg valami elhalt task kapaszkodik a device-ba. Ha mountolva van, umount. eject próba. Ha az umount ment, de mégsem adja ki, akkor a device-ra akadt rá valaki, ezt lsof paranccsal derítsd ki, lödd ki a taskot – kill -9 – és eject.
Rosszabbik eset: kilöhetetlen zombi-hoz van rendelve az eszköz. (van ilyen). No ekkor csak reboot. És akkor is reboot legtöbbször, ha a program olyan állapotban hagyta az égetöt, hogy az nem akar kommunikálni. Ez utíbbi esetben nem a reboot a lényeg, hanem az újratöltés elött / közben a berendezéseknek küldött HW reset. (Általában külön dróton). Nagyon ritkán még ez sem használ, akkor ki kell kapcsolni a gépet, meg be. Ilyet is láttam már.
