oneliner Linux stop!

 ( wyx | 2019. január 30., szerda - 15:53 )

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?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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?

Az nem probléma számodra, hogy ez nem synceli a disket és unmount sincs?

Itt a lenyeg, hogy szimulaljunk egy kernel panic-ot. failover testekhez kell.

A fent idézett sysq trigger megfelelő lesz, csak előtte nézzétek meg, hogy engedélyezve van-e.

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

ifdown eth*

problem solved.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

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.

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!

pontosan

jah, google keresni en is tudok, de kosz, hogy atkuldted.

na de akkor mi is a kerdesed?

--
O1G = orbanegygeci

Probalj meg elore olvasni.
(a masodikhoz meg a kerdes az, hogy biztonsagos e?)

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

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.

Teljesen biztonságos:

sudo shutdown now

Leállításához hasonló dolgot művel, a gép csak csendben leáll...

Echo 'Xy problem' >/dev/kmem

ezt lattad? "nem ir at fontos memoriateruleteket,"

--
O1G = orbanegygeci

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...

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."

Nolatod, ratalaltal. Pl. a legpuskaval ezt meg tudod tenni :D

[off]
Viszont hangtompito tesztelesere nem jo :D
[/off]

-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

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

Az initet már nem lehet így kilőni systemd alatt.

A regi jo dolgokbol semmi nem marad :D Subs.
____________________
echo crash > /dev/kmem

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."

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...

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."

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

Hacsak nem kifejezetten egy ilyen crash szimulálása a feladat, akkor egy megfelelően célzott iptables drop segíthet.

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

4. comment...