Linux stabilitás 2016

Testvérem gépe, feldobta a talpát, de vajon hogyan is? Stílszerűen, öngyilkos lett.
Történt ugyanis, hogy a tegnapi nap folyamán, délelőtt letette a gépet suspendbe és eljött halottébresztőset játszani. Estére hazaérve, szépen mákosan találta a monitort és a gép semmit nem reagált. Nyomott neki egy resetett, mire az Ubuntu újraindult, és az fsck- agyhalottra darálta a rendszerpartíciót. Nagyjából két és fél óra molyolás után sikerült életre kelteni úgy, nagyjából egy marék csontot rázogatva kitaláltuk, hogy vajon melyik konfig fileokat találta feleslegesnek a "javítprogram". A dolog iróniája, hogy az FSCK ténykedése egy nagyjából 10 éve fennálló probléma és baromira nem értem, hogy ez miért nem szúrja senkinek a szemét. Elég sok olyan géppel dolgozom, amik alól a felépítésük, alkalmazásuk folytán (SBC, mérés adatgyűjtő, alternatív energia ellátás, kisgyerek a háznál, stb) rendszeresen eltűnik a tápfeszültség. Egy modern operációs rendszertől elvárható lenne, hogy ez ne okozzon fennakadást a működésében. Ugyancsak érdekes, hogy vajon miért van, hogy egy nem használt filerendszer esetében, milyen hibát is tud találni az ellenőrző program? Ez azért érdekes, mert volt rá precedens, mikor egy netes loggolás alatt álló gépen, olyan libeket "javított" ki, melyeket a logok szerint 32 nappal korábban olvasott utoljára az alkalmazás.
A hab a tortán, hogy a suspend esetében, mi akadályozza meg az OS-t, hogy unmountolja a köteteket és visszatérésnél újramountolja? Emlékeim szerint, suspendnél, nem tevékenykedik a gép, magyarán nincs i/o tevékenység, ha meg van esemény amit kezelnie kell, akkor úgyis visszatér aktív állapotba.
Szóval, a nagy Linux desktop fejlesztés közben ott tartunk, hogy egy FAT32-re telepített XP, vagy egy jó öreg DOS megbízhatóbb.

( hajduarpad | 2016. 11. 01., k – 17:13 )

Lazan kapcsolodik:
- 2TB fajlrendszer, ext3, kb 100 fajl, DB2 adatbazis -> miert tart az fsck 3 oran at ???
- 30G fajlrendszer, ext4, kb 14 millio fajl nagyjabol egy mappaban -> miert hal bele az fsck a directory ellenorzesbe 32G memoria mellett?
- Plusz pl van egy szerver fut 1 even at, reboot es nekiall fsck-zni (alapertelmezett beallitasok mellett) ... megertem en, hogy a fejlesztok biztosra akarnak menni de ha valaki elcseszi az fstab-ot es bentmarad az fsck flag miert kell kenyszeriteni az ellenorzest csak mert tul regen volt utoljara ? Sosem hallottak meg a devek NAGY fajlrendszerekrol ?

Szerintem orakig lehetne sorolni a Linux fsck koncepciojanak hibait...

( szegecs | 2016. 11. 01., k – 17:45 )

Jó de hogy ontopicok legyünk, az Apple Touch ID-ről mi a véleményed? Nameg az ESC. Meg a Google, ami szerintem jócég. Bezzeg az M$, pfoj még bugot se bírnak javítani 7 napig. Linus bezzeg ("badly").

--
sent from @ oneplusone

( uzsolt v | 2016. 11. 01., k – 18:34 )

Milyen fájlrendszer? Az fsck a linux "része"?
Nem akarok én védeni senkit és semmit, de a blogbejegyzés címe enyhén félrevezető.

( kovi | 2016. 11. 01., k – 20:11 )

sajnos az otthoni Linux-felhasználók igénye mára közelít a fentebb írt színvonalhoz, máskülönben nemigen lehetnének ekkora szopások. habár talán van még remény, hiszen két perc alatt már nem jön a bejegyzésedre három marék válasz írjál jobbat; szuvenyír nyihaha; nálam tök jó minden tartalommal.

szóval ha jogos károgásról van szó, akkor úgy általában korábban kellett volna kezdeni. magamnak is mondom. klasszikus példával élve "tetszettek volna forradalmat csinálni".

--
Vortex Rikers NC114-85EKLS

( locsemege v | 2016. 11. 01., k – 22:19 )

suspend esetében, mi akadályozza meg az OS-t, hogy unmountolja a köteteket és visszatérésnél újramountolja?

Szerintem az, hogy suspend esetén futás közben kerülnek az alkalmazások megfagyasztásra, file-ok tömkelege van éppen nyitva, minden marad RAM-ban, így aztán nem lehet lecsatolni a filerendszereket.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Khm, khm, khm...
Suspend esetében mi akadályozza meg a kernelt abban, hogy a processzeket megállítsa, a nyitott fileokat a meghajtón lezárja, a köteteket leválassza, majd a suspendből visszajövetelnél újból mountolja a köteteket, a fileokat megnyissa és újból engedélyezze a processzeket? Hmmm? A processzek által megnyitott fileok elég jól vannak követve, mindössze egy műveletsort kell beiktatni a suspendbe.
Ha suspend alatt sérül a memória állapota, akkor az újraindulásnál a filerendszerek állapota tiszta lesz, de ehhez tervezni kell.
Jelenleg a suspend, érzésem szerint, erősen a "wishfull thinking" szerint van megalkotva. Az-az lemegy a rendszer suspendbe, és mindenki reménykedik, hogy nem történik semmi "váratlan" mindeközben.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Triviálisan: A process megnyitja X fájlt írásra, kap egy file handle-t, írogat bele. B process törli X fájlt. Lepausolod a processzeket, kivágod alóluk a nyitot file handle-ket, umount, suspend.
Resume-kor hogy kapja vissza X azt a handle-t, amit B már törölt és az általad kikényszerített handle lezárás és umount véglegesen eltávolított (mivel a fájlrendszerből már nem elérhető)?

És azért ez az állapot nem ritka, és csak egy a sok közül, ahol borulhat az ötleted.

Van ilyesmi, a CRIU nagyon hasonlót csinál (processek suspendje), itt-ott patchelt kernel kell neki, és csomó mindent még így sem tud menteni...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( trey | 2016. 11. 02., sze – 09:33 )

Néhány szót említhetnél arról, hogy

- milyen gép
- ki tervezte
- ki rakta össze
- milyen alkatrészekből
- stb.

Mert ez így csak egy random picsogás.

--
trey @ gépház

Mi köze is van mindennek ahhoz, hogy az fsck ledarálta a rendszerpartíciót? Van talán "brand detection" kapcsoló? Vagy ha nincs AppleID, akkor az fsck szopjál plebs módban indul? Ezek új dolgok lehetnek.
Mert ugye, itt nem azzal volt a probléma, hogy elszállt a suspend (ami ugye egy alapban nem biztonságos üzemállapot), hanem az, hogy a filerendszer ellenőrző olyan fileokat is hazavágott (pl. xorg.conf, dhcpd.conf) amik jelen üzemállapotban, olvasásra voltak megnyitva. És ez itt a probléma.
Oh, és ugyanezt a problémát bármelyik gépen elő tudod hozni, elég csak kirántani a konnektorból. Igen, lehet mondani, hogy miért nincs UPS mögötte, de egy generikus OS-től, hadd várja el az ember, hogy kezelni tudja a "nem szabályos" rendszerleállítást.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Szia!

A probléma nálad lehet:

Tegnap előtt ment el az áram a helyen ahol dolgoztam (épp villanykörtét cseréltem az egyik lámpában eközben). Ekkor tapasztaltam, hogy valahol a zsírúj körte és a lámpa foglalata között zárlat van. Szikrázott annak rendje és módja szerint, legvágta a biztosítékot is. Mikor visszakapcsoltam a gépet, minden ment tovább. (Ubuntu 16.04, ext4)

Üdv.

Az, hogy én még életemben nem találkoztam ilyennel. Se desktopon, se notebookon, se szerveren. Se HDD-vel, se SSD-vel. Se ReiserFS-en (10+ éve alatt), se Ext* fájlrendszeren. Se elment áram esetén, se lemerült akku esetén. Se normál esetben, se suspend alatt.

Ja és 10+ éves úgy működik a suspend / resume nekem, hogy 0 probléma.

Arról még mindig nem tudunk, hogy

- neked mitől rohadt meg a suspend (valaki azt hitte, hogy tud gépet tervezni és összerakni, de mégse)
- milyen alkatrészekből áll a gép (szarfos / ósdi / bugos alkatrészek / BIOS / ACPI stb.)
- szedett-vedett memóriakonfiguráció
- bad sectoros HDD / SDD
- eső-kelő alaplap (kiszárad elko stb.)

esetleg szóba jöhet-e. A végtelenségig sorolhatnám.

Ellenben láttam már hibás / rosszul összerakott gépekből fakadó problémákat, amit - érdekes módon - kijavítva, a hibák megszűntek.

--
trey @ gépház

Az, hogy én még életemben nem találkoztam ilyennel. Se desktopon, se notebookon, se szerveren. Se HDD-vel, se SSD-vel. Se ReiserFS-en (10+ éve alatt), se Ext* fájlrendszeren.

Én reiserfs-nél találkoztam hasonló, rövid idő alatt többször előforduló szabálytalan leállás/suspend/lefagyás után. De ennek már van vagy bő tizenvalahány éve, és végül ezért hagytam el a reisert. A részletekre már nem emlékszem. A probléma lényege a többszöri szabálytalan/sikertelen lecsatolás volt ennyi még rémlik :-).

Én azt tippelem így látatlanban, hogy a suspend/OS nem előszőr fagyott meg az utóbbi időben az említett gépen. Az első néhány alkalommal még nem volt gond, aztán valamelyik sokadik alkalom után kinyírta a fájlrendszert.

A suspend lefagyására örök tipp a wifi/bluetooth driver. Gányolással egy szkripttel le kell lőni közvetlen suspend előtt, ébredéskor meg visszatölteni kernelmodulostul/daemonostul.

Hienanak:

U.I.: Azért egy alapos memtest ráférne a gépre. :-)

U.I 2: Ha ennyire stabil a rendszer, érdemes lenne a suspend előtti szkriptbe egy olyan gányolást betenni, ha van Zombie processz, akkor törje meg a suspendet.

U.I 3: "egy FAT32-re telepített XP, ". Hát el kell keserítselek. Volt szerencsém anno több xp-hez és bizony a többszörös lefagyogatósdi után bizony a chkdsk is szétkúrta időnként a fat32-t. :-)))

--------

Előállított "Vállalati
Internetszennyező"

Jaj, hát ilyen rémtörténeteket számtalanszor hallottam már.

De azért, hogy legyen benne valami tétje is, itt és most állok elébe a dolognak. Én minden nap több alkalommal suspendelem / resume-olom a gépem. Itt vannak az adatok:

trey@alderaan:~$ sudo tune2fs -l /dev/sda2
tune2fs 1.43.3 (04-Sep-2016)
Filesystem volume name:
Last mounted on: /
Filesystem UUID: 2edcc9b4-a394-4297-b1ad-3fafbe275b27
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 29818880
Block count: 119275520
Reserved block count: 5963774
Free blocks: 73113243
Free inodes: 29412650
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 995
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stride: 32741
Flex block group size: 16
Filesystem created: Sat Feb 14 17:13:16 2015
Last mount time: Thu Oct 20 19:20:07 2016
Last write time: Thu Oct 20 19:20:07 2016
Mount count: 6
Maximum mount count: -1
Last checked: Wed Oct 19 18:30:27 2016
Check interval: 0 ()
Lifetime writes: 3327 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 6292035
Default directory hash: half_md4
Directory Hash Seed: 7a80415c-553f-4759-bbba-3c5a47e79824
Journal backup: inode blocks

Ennek csakhamar el kell pusztulnia (vagy már rég el kellett volna?), ha jól értem "Linux stabilitás 2016".

Kíváncsi leszek.

--
trey @ gépház

Én minden nap több alkalommal suspendelem / resume-olom a gépem.

Ahogyan én is, csak nekünk hiena tesójával ellentétben ettől nem fagy le a gépünk. De ha nincs huzamosabb ideig használatban a gép, akkor rendesen le is állítom.

szerk: +pár sor az elejére: 


Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1609600
Block count:              3273728
Reserved block count:     163684
Free blocks:              292739
Free inodes:              1362101
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16096
Inode blocks per group:   503
Last mount time:          Fri Nov  4 17:35:57 2016
Last write time:          Fri Nov  4 17:35:50 2016
Mount count:              10
Maximum mount count:      27
Last checked:             Mon Oct 31 09:06:05 2016
Check interval:           12096000 (4 months, 2 weeks, 6 days)
Next check after:         Mon Mar 20 09:06:05 2017
Lifetime writes:          26 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea

Ez sajnos olyan régi fájlrendszer, hogy még nincsen benne filesystem created adat. :-)

--------

Előállított "Vállalati
Internetszennyező"

>> Én minden nap több alkalommal suspendelem / resume-olom a gépem.
> Ahogyan én is, csak nekünk hiena tesójával ellentétben ettől nem fagy le a gépünk

Heti szinten sikerül nem tiszta módon újraindítanom a laptopomat, néha suspend közben megfagyás miatt. És én sem tapasztalok iilyen hibákat. Olyan már volt értelemszerűen, hogy épp írt fájl korruptálódott, de olyan amihez hozzá se nyúl a rendszer azt hogy? Valaminek kell lenni a háttérben ami több mint a "linuxszar"

( salaud v | 2016. 11. 02., sze – 12:11 )

Most csak a te kedvedért kiveszem az akut a laptopból, majd hirtelen kihúzom a töltőt, majd vissza és bebootolom az xubuntut.
fsck beállításokhoz nincs semmi hozzányúlva.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Bebootolt, fsck nem futott. Xubuntu 16.04 LTS, ext4 a filerendszer. Hiba nincs.
---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Hogyhogy nem?

Win98 óta a nem tervezett leállások után a ScanDisk opcionálisan lefut indítás során, még azelõtt hogy az OS nagyon mókolna a potenciálisan hibás file-rendszerrel.

Az ext4 véd ez ellen, átállítottad, vagy, tényleg az az alapbeállítás hogy nem lehet indítás elõtt fsck-ozni?

Nem nyúltam hozzá, alapbeállításon van. Amúgy elgondolkoztam, ext4 használata óta kb 1x láttam fsck-t futni, amíg anno ext3 volt, meg reiserfs, akkoriban még le-lefutott. Most direkt megnéztem a /var/log/fsck/ mappában a logfile-okat, üresek. Mióta ez a telepítés fut, nem volt fsck használva a gépen.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

( winben | 2016. 11. 02., sze – 22:32 )

Otthon szüleimnél egy Digis Kaon HD beltéri box csinálja azt 10-ből 9x, hogy áramszünet esetén mikor újra áramot kap a készülék infinite loopba kerül - bekapcsol, felpörgeti a rádugott USB vinyót képet ad, kiírja egy pillanatra, hogy "várjon", majd vinyó leáll, dob egy restartot és kezdődik minden elölről.

Rájöttem ám, hogy sqlite-ot használ a kis drága és a lemezen lévő DB sérült ilyenkor és emiatt képtelen lekezelni értelmesen a problémát. Pedig a megoldás egyszerű: usb vinyó kihúz, rádugom laptopra, fsck az ext3-as fájlrendszeren, kijavít 1-2 hibát és sálálá, visszadugva megy tovább minden, felvételek is megmaradnak.
Szóval abba a sz*ros beltéri boot folyamatába igazán rakhattak volna egy fsck-t is hamár amúgy is naplózó fájlrendszer, nem tartana olyan sokáig.
Ellenben a beltérit nem lehet biztonságosan kihúzni a konnektorból, mert akkor is ez történik, ha a beltérit kikapcsolod és némi molyolás után még le is állítja a vinyót. És a beállításokban igen, van olyan, hogy USB HDD biztonságos eltávolítása - ám ekkor (gondolom szerzői jogvédelmi ...ság) figyelmeztet, hogy ehhez le kell formáznia a merevlemezt, szóval az sem járható út, marad az oroszrulett.

Szóval ebben az esetben is azt gyanítom, hogy a db nyitva marad az eszköz csak suspendel, áramszünet esetén a disk korrumpálódik és következő indításkor képtelen ezt bárhogyan is helyrehozni.

---------------------------------------
Devmeme - fejlesztői pillanatok

Szerintem

tune2fs -c 1 /dev/sdb1

a device értelemszerűen.

Különben a naplózó filerendszer nem garantálja azt, hogy szabálytalan leállásnál nem lesz adatvesztés, pusztán a konzisztencia állítható vissza a naplóból. Szóval lesz egy egészséges filerendszered, de senki sem mondta, hogy a disk cache-ben lévő adat valami csoda folytán az adatbázis file-okba fog íródni nulla idő alatt, így a DB simán elhalhat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem az időre utaltam, hanem arra, hogy a journal arra jó, hogy lesz egy garantáltan konzisztens, stabil filerendszered, de ettől még bukod azokat az adatokat, amelyek a disc cache-ben voltak a szabálytalan leállás pillanatában. Alkalmazás rétegben, például adatbázisban ez okozhat inkonzisztenciát.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( bucko | 2016. 11. 04., p – 01:21 )

... mákosan találta a monitort és a gép semmit nem reagált. Nyomott neki egy resetett, mire az Ubuntu újraindult ...
Nos, a suspenben levő gépnek ilyenkor semmi köze a linuxhoz. Persze a nem suspendnek sem.
Amit leírtál az hardver hiba.
Innentől kezdve egyes számú ökölszabály:
Először megjavítjuk a hardvert és csak utána indítunk bármit!
A kettes szabály:
Semmit nem indítunk el, amíg a rendszer nem konzisztens.

Ezek után lehet bármilyen egyéb programot indítani.

A szabályok érvényesek olyan operációs rendszerre is, amely megfelelő hardveren fut, képes azt alacsony szinten kezelni és diagnosztizálni is. (Pl. AIX)
Természetesen fokozottan érvényes az olyanokra, amelyek egyik fenti tulajdonságal sem rendelkeznek és a hardver sem biztosítja ezt. (Pl. Windows és linux pc hardveren.)

A fenti szabályok nem vonatkoznak az egyszerű felhasználókra, mivel lila fingjuk sincs mitől állt meg a gép. ;)