Tud valaki olyan "oneliner"-t (foleg bash), amely kernel crash-t okoz Linuxok alatt, de "aranylag" biztonsagos, azaz nem ir at fontos memoriateruleteket, amely FS (vagy barmi mas) inkonzisztenciat okozhat?
- 3087 megtekintés
Hozzászólások
jah, google keresni en is tudok, de kosz, hogy atkuldted.
Olyan kellene, ami bizonyitottan mukodik minden ujabb Linux-on es tenyleg tesztelt biztonsagossagi oldalrol.
A
echo c > /proc/sysrq-trigger
tunik jonak, ellenvetes?
- A hozzászóláshoz be kell jelentkezni
Az nem probléma számodra, hogy ez nem synceli a disket és unmount sincs?
- A hozzászóláshoz be kell jelentkezni
Itt a lenyeg, hogy szimulaljunk egy kernel panic-ot. failover testekhez kell.
- A hozzászóláshoz be kell jelentkezni
A fent idézett sysq trigger megfelelő lesz, csak előtte nézzétek meg, hogy engedélyezve van-e.
- A hozzászóláshoz be kell jelentkezni
Miért nem elég csak "eltüntetni" azt a hostot amit most meg akarsz ölni. Gondolom ha failover kell akkor van egy másik host ahova átmászhat a szolgáltatás. Ebben az esetben elég a netről lecsapni, azt fogja látnia másik hogy nem jön a heartbeat és failoverel.
===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)
http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation
- A hozzászóláshoz be kell jelentkezni
ifdown eth*
problem solved.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház
- A hozzászóláshoz be kell jelentkezni
crash esetén még ARP cache maradhat a switchben szemben az ifdown esetén úgy rémlik a switch azonnal üríti, tehát eltérő teszteset lesz a végén...
(kábel kihúzás dettó)
mondjuk alkalmazás függően hálózati oldalról esetleg iptables DROP -al illetve egyes ritka esetekben REJECT-el lehet játszani, ami hasonlíthat egy crashre (input és output láncon egyidejűen).... bár ezzel is valószínűen lehet vitatkozni.
- A hozzászóláshoz be kell jelentkezni
Potenciális válasz: a hálózatról leszakadás és kernel crash két külön teszteset.
A túlélő node-ra failover szempontjából alapesetben nincs difi. A recovery viszont nagyon eltérő lehet.
Olyan kérdések merülnek még fel, hogy pl kdump crash recovery kernel van-e konfigurálva, illetve van-e ráépítve valami? Pl láttam olyat, aki snmp trap küldést kötött a crash recovery kernel early userspace-be, ezzel csinált egy utolsó "halálsikolyt" az éppen crashelő gépnek. Mi inkább azt preferáltuk, ha a túlélő node küldi az alarmot az elveszett clustertagról. A kdump-ról úgy tartom, hogy leginkább a sysrq-c (echo c > /proc/sysrq-trigger) szimulált kernel crash esetén működik megbízhatóan, valódi crash esetén szerencse és kiváltó ok kérdése (erről ritkán van releváns tapasztalat).
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
pontosan
- A hozzászóláshoz be kell jelentkezni
jah, google keresni en is tudok, de kosz, hogy atkuldted.
na de akkor mi is a kerdesed?
- A hozzászóláshoz be kell jelentkezni
Probalj meg elore olvasni.
(a masodikhoz meg a kerdes az, hogy biztonsagos e?)
- A hozzászóláshoz be kell jelentkezni
ettől simán, és azonnal crash-el a kernel.
Hogy milyen inkonzisztenciát okoz, azzal ő nem törödik.
Attól főgg éppen mi futott, és amennyire érzékeny ilyenre.
Szvsz biztonságos "kernel crash" nincs.
--
zrubi.hu
- A hozzászóláshoz be kell jelentkezni
Nem biztos, hogy ez a jó irány, de mi van, ha előbb van egy sync és utána read-only-ra váltani a fájlrendszereket, s úgy kress.
Ha ez már nem elég jó a teszthez, akkor csak az marad, hogy backupból/snapshotból utána helyreállítod az egész vm-et/környezetet.
- A hozzászóláshoz be kell jelentkezni
Teljesen biztonságos:
sudo shutdown now
Leállításához hasonló dolgot művel, a gép csak csendben leáll...
- A hozzászóláshoz be kell jelentkezni
Echo 'Xy problem' >/dev/kmem
- A hozzászóláshoz be kell jelentkezni
ezt lattad? "nem ir at fontos memoriateruleteket,"
- A hozzászóláshoz be kell jelentkezni
Már-már kezdem azt hinni, hogy a kolléga mások számítógépét akarja megdönteni... Tréfából vagy valamiféle másolásvédelmi ellenőrzés részeként...
- A hozzászóláshoz be kell jelentkezni
Miért pont kernel chrash?
Mi a baj a shutdown-al?
Kernel chrash inkonzisztencia kockázat nélkül?
Kicsit mintha azt kérdezted volna, hogy melyik az a lőfegyver, amellyel aránylag biztonságos módon tudom szíven lőni bármely embertársamat. :)
---
"A megoldásra kell koncentrálni nem a problémára."
- A hozzászóláshoz be kell jelentkezni
Nolatod, ratalaltal. Pl. a legpuskaval ezt meg tudod tenni :D
- A hozzászóláshoz be kell jelentkezni
[off]
Viszont hangtompito tesztelesere nem jo :D
[/off]
-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
- A hozzászóláshoz be kell jelentkezni
Ez már nem működik újabb kernelen (forkbomb)?
:(){ :|:& };:
Vagy pedig: sudo kill -9 1
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház
- A hozzászóláshoz be kell jelentkezni
Az initet már nem lehet így kilőni systemd alatt.
- A hozzászóláshoz be kell jelentkezni
A regi jo dolgokbol semmi nem marad :D Subs.
____________________
echo crash > /dev/kmem
- A hozzászóláshoz be kell jelentkezni
miért, systemd előtt lehetett? én úgy tudtam PID 1 alapból nem vesz be egy csomó signalt, de javíts ki ha tévednék
"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."
- A hozzászóláshoz be kell jelentkezni
Hehe :)
Buguntu 18.04 WSL-t kiakasztotta rendesen. De a windows is elkezdte pörgetni a 4 magot 100-on. :D
---
Amíg a test renyhe, az elme dolgozik...
- A hozzászóláshoz be kell jelentkezni
ulimit értékétől függ tudtommal, de ezt nem mondanám túl elegáns megoldásnak.
"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."
- A hozzászóláshoz be kell jelentkezni
Fedora 29 túlélte. Dobott egy rakás üzenetet:
bash: fork: Resource temporarily unavailable
CPU kihasználtság 100 %-on volt - mind a négy mag -, illetve megevett egy rakás RAM-ot, de a végén feladta, a gép stabil maradt. Sőt, még az a shell is működik tovább, amellyel ezt elkövettem.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Hacsak nem kifejezetten egy ilyen crash szimulálása a feladat, akkor egy megfelelően célzott iptables drop segíthet.
- A hozzászóláshoz be kell jelentkezni
Mihez kell ez neked pontosan? Mit akarsz vele tesztelni? Tudom, semmi közünk hozzá, de legalább általánosságban leírhatnád, lehet, hogy a kernel crasheltetésén kívül vannak rá jobb módszerek.
No keyboard detected... Press F1 to run the SETUP
- A hozzászóláshoz be kell jelentkezni
4. comment...
- A hozzászóláshoz be kell jelentkezni