Force reboot

Csak, hogy sose felejtsem:
root
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

( locsemege v | 2015. 07. 10., p – 20:49 )

Ez ebben a formában nem umount-olja a filerendszereket, lényegében olyasmi, mintha reset-et nyomtak volna a gépnek, jól gondolom?

Egyébként:

systemctl reboot

systemctl --force reboot

systemctl --force --force reboot

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

sysrq.txt-ből:
'b' - Will immediately reboot the system without syncing or unmounting
your disks.

Egy drive I/O erroral elszállt rendszernél megnézem amíg eljut az unmountig a systemd... Hiába, fejlövés az fejlövés.
EA 00 00 FF FF és CD 19 forever!
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

0xEA: JMP ptr16:16 http://www.felixcloutier.com/x86/JMP.html
00 00 FF FF -ből jön ki a FFFF0h cím, ami x86-nál a reset vector https://en.wikipedia.org/wiki/Reset_vector

0xCD: INT imm8 http://www.felixcloutier.com/x86/INT%20n:INTO:INT%203.html
19h: "A program can call this interrupt to reboot the computer" https://en.wikipedia.org/wiki/BIOS_interrupt_call

Nem hiszem, hogy védett módban (összes mai OS ilyen) ez működne.
DOS alatt működik, meg lehet írni assembly-ben vagy ha már úgyis ott az utasításkód, akkor hexeditorban.

Ki lehet próbálni: 

$ ( echo -ne "\xEA\x00\x00\xFF\xFF"; head -c $((512-2-5)) < /dev/zero | tr '\0' '\141'; echo -ne "\x55\xAA" ) > asd.img
$ kvm asd.img

vagy 

$ qemu asd.img

Az első echo a fent leírt utasítást és címet adja, az utána lévő head+tr csak helykitöltést csinál, hogy a második echo a jó helyre írja a bootolhatóságot jelző 0x55 0xAA -t.
Ha elindítod, a virtuális gép erről fog bootolni, és rögtön újra is indul.
Ha dd-vel rámásolod egy pendrive-ra (dd if=asd.img of=/dev/sdX; partíciós tábla, a filerendszer és minden adat elveszik!) akkor ki lehet próbálni rendes gépen is.

A systemctl --force --force reboot meg sem próbálja az umount-ot a doksi szerint:

If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss.

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

( kmARC v | 2015. 07. 11., szo – 04:37 )

Ujszulottnek minden poen uj ugyebar. Welcome! :)
google://REISUB

( zaphodb v | 2015. 07. 11., szo – 13:02 )

az átirányítás előbb kerül értelmezésre.

En hasznalnam a helyedben az egergorgot...

Egyebkent, ha mindenkepp onelinerben akarod, akkor igen, sudo bash -c "echo foo > /dev/null"

Amugy su != sudo

Egyebkent ez tipikus peldaja annak, amikor utana kell gondolni, hogy mi hogyan mukodik amikor beutsz egy parancsot. Az atiranyitast ugyanis nem a meghivott parancs fogja ertelmezni, meg csak nem is a kernel, hanem az a parancsertelmezo, ahova a parancsot atiranyitassal egyutt begepelted. Tehat, az a fajl, amibe atiranyitasz, az nem a parancs altal kerul megnyitasra, hanem a meghivott parancs STDERR, STDIO es/vagy STDOUT fajlleiroi lesznek freopen(3)-elve az atiranyitott fajlra. Ha nincs jogod a celfajl irasra torteno megnyitasara, akkor permdeniedet kapsz.
--
Blog | @hron84
Üzemeltető macik

A tee paranccsal láttam, az megvolt, ötletesnek is tartom, de egyrészt nem tudtam, hogy a sudo a pipe buffert átadja az argumentumában hívott programnak, másrészt picivel jobban áttekinthető szerintem, amikor már a shell root joggal fut, s abban minden, így az stdout átirányítás is root jogú lesz.

Nem állítottam, hogy a sudo és a su azonosak lennének, csak azt, hogy a su-val meg lehet tenni, hogy az argumentumaként megadott script a su által meghatározott joggal fusson, s ebből gondoltam, ez akár a sudo esetén is lehetne így. Bár tény, hogy így ki lehetne kerülni a sudoers-ben megadott szabályokat, ami nem lenne jó.

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

su -c 'echo foo' > /dev/null

Ez itten ugyanugy root joggal indulo echo, ami userkent iranyit at. Amire te gondlsz, az a su -c 'echo foo > /dev/null', de ugye a su az mindenkeppen forkol egy komplett uj shellt (egeszen pontosan egy uj PAM login tortenik a root neveben), mig a sudo az suid-os varazslattal dolgozik, es ugyan odafordul a PAM-hoz, de nem tortenik egy kompletten uj login.

Egyebkent azt hiszem, hogy a sudoers pattern match-csal dolgozik, vagyis a sudoersben megadott szabalyok eleg konnyen megkerulhetoek, ezert kell inkabb wrapper scripteket megadni a sudoers-ben.

Ami a pipe buffert illeti, atadja, mert a child processzek egyszeruen igy mukodnek, megoroklik a szulo file descriptorait.
--
Blog | @hron84
Üzemeltető macik

Magát a problémát értettem kezdettől fogva, pusztán a megoldás szintaxisát kerestem. Az világos, hogy a sudo parancs >file esetében a parancs lesz más jogú, az átirányítás viszont a sudo-t is indító shellben hajtódik végre.

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

( hrgy84 | 2015. 07. 11., szo – 22:37 )

sudo echo... juj.

echo 1 | sudo tee /proc/sys/kernel/sysrq
echo s | sudo tee /proc/sysrq-trigger
echo u | sudo tee /proc/sysrq-trigger
echo b | sudo tee /proc/sysrq-trigger

A sudo echo eseteben az echot elsutod root-kent, majd user joggal megprobalod leirni a kimenetet. ha nem egy kover permdenied a vege, akkor ott valami eleg nagy gaz van.
--
Blog | @hron84
Üzemeltető macik

Fönti eszmecserét olvasgatva, pár dolognak utána járva tényleg súlyos hiba volt sudo echo, pedig logikusan úgy gondoltam sudo echo 2 >> /xyx/yxx után csak passwordot fog kérni. Mint például egy sudo apt-get install ggjkgkjg esetén. Tanulság => Mindig ki kell próbálni, és csak aztán beírni.

No, nem. Eddigi tapasztalatom alapján, ha egy operációs rendszernek nevezhető entitáshoz nincs
- a fenti feladatkör ellátásához előre kidolgozott parancs,
- és ennek megfelelő dokumentációja,
- és minderről fórumozgani kell,
akkor rákérdezek. Akár durván is.
(Kollégám szerint: entitás == izé ;))
A beszélgetés tárgyából a windows-féléket önkényesen kizártam. :(

"magába fordult gépet újra kell indítani?" - Erre írtam: "No, nem."

"a fenti feladatkör ellátásához előre kidolgozott parancs" - Lásd a topic címe (ott egészen fenn): "Force reboot"

"Mielőtt hozzászólsz valamihez, nem árt, ha elolvasod! Sőt, megérted, amit olvastál!" - Ez meg akár egy Slavor Hardin epigramma is lehetne - bár én írtam. :)

"A grafikus felület megdöglése nem magába fordulás."

Ez erosen az attol fugg kategoria. Egyre tobbszor jon az elo, hogy a grafikus felulet meghal, es az X mar annyira sem erolteti meg magat, hogy a Ctrl+Alt+Fx kombinaciokat lekezelje. Olyankor max ssh-n keresztul eleg korulmenyesen tudnam csak a gepet ravenni az egyuttmukodesre, szoval en azt is ugy kezelem, mintha belso parbeszedbe kezdett volna onmagaval az elet ertelmerol.
--
Blog | @hron84
Üzemeltető macik

Igen, ez valóban kellemetlen, velem is előfordult. Ha működik a gép, akkor a kikapcsoló gomb megnyomását még elhiszi, ssh-n is reboot-ot mondanék neki, ám a kikapcsoló gomb egyszerűbb. Probléma akkor van, ha a kikapcsoló gombot hosszan kell nyomni.

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

Jól látod! A magába fordult az hajszálpontos műszaki-tudományos-filozófiai-fingomsincs. :D

Az X csak egy program, kilőhető. De itt egy életből ellesett (aztán majd elmagyarázom ;) példa, amit nem magába fordulásnak hívok, hanem "befagyott a kernel". Szakember által gondosan NEM peccselt filesystem driver intenzív terhelés mellett többé nem tért vissza az open() hívásból. A futtatott rendszer is megállt úgy 120 befagyott tranzakció után - mivel monda: lock és itt mintha elvágták volna...

Ekkor a kernel még javában működik, be is lehet jelentkezni. De mindenképpen indokolt a legkevesebb tevékenységgel járó reboot.

A magyarázat: Ugyan életből ellesett a péda, azaz éles rendszeren fordult elő a hiba. Mégis azt mondanám, hogy ez csak más számára életszerű. Ugyanezen a rendszeren több, szakértelmet nélkülöző dilettáns megoldás is előfordult. Az a véleményem, hogy egy rendesen elkészített rendszeren a "force reboot" nem igazán életszerű.