- This topic has 32 hozzászólás, 7 résztvevő, and was last updated 17 years, 1 months telt el by
.
-
Bejegyzés
-
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.
És még flexel is ki lehet nyitni. :))) De attól, hogy mechanikusan kiveszed, attól az os szerint még bent marad és továbbra sem fog működni sem az írás, sem az olvasás.
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.És még flexel is ki lehet nyitni. :))) De attól, hogy mechanikusan kiveszed, attól az os szerint még bent marad és továbbra sem fog működni sem az írás, sem az olvasás.
birno wrote:gendelider wrote: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.umount magában nem ment, „device busy” pedig elvileg semmi nem fogta, most lsof-t nem néztem, de máskor is volt ilyen s nem látott semmit(vagy én voltam béna).
„umont -l”-el lecsatolta, de kiadni nem adta.Első körben én megnézném, hogy az eject miért nem szeretne működni… ha hajlandó kiírni.
Code:eject -v …birno wrote:gendelider wrote: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.umount magában nem ment, „device busy” pedig elvileg semmi nem fogta, most lsof-t nem néztem, de máskor is volt ilyen s nem látott semmit(vagy én voltam béna).
„umont -l”-el lecsatolta, de kiadni nem adta.Első körben én megnézném, hogy az eject miért nem szeretne működni… ha hajlandó kiírni.
Code:eject -v …Amúgy, hogy van-e zombid azt így is megnézhetetd:
Code:ps aux | awk ‘{ print $8 ” ” $2 }’ | grep -w ZKicsit lényegretörőbb, mint a top/htop. 🙂
Amúgy, hogy van-e zombid azt így is megnézhetetd:
Code:ps aux | awk ‘{ print $8 ” ” $2 }’ | grep -w ZKicsit lényegretörőbb, mint a top/htop. 🙂
Huh, közben természetesen már megvolt a reboot, de megpróbálom reprodukálni a hibát és kipróbálom ezeket.
Huh, közben természetesen már megvolt a reboot, de megpróbálom reprodukálni a hibát és kipróbálom ezeket.
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.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz