Ludzie, którzy nie rozumieją terminala, często boją się go używać w obawie, że mogą zepsuć swoje polecenie i spowodować awarię komputera. Ci, którzy znają Terminal, lepiej wiedzą, że tak nie jest - zwykle Terminal po prostu wyświetli błąd. Ale czy istnieją polecenia, które spowodują awarię komputera?

OSTRZEŻENIE: możesz stracić dane, jeśli je wpiszesz lub skopiujesz, szczególnie polecenia sudoi rmpolecenia.

Jednym ze sposobów na awarię komputera jest wykonanie tzw. Bomby widełkowej .

Możesz go wykonać na systemie uniksowym poprzez:

:(){ :|: & };:

Jest to polecenie, które rekurencyjnie spawnuje procesy, aż system operacyjny będzie tak zajęty, że nie będzie już reagował na żadne działanie.

Nie masz pewności, co masz na myśli mówiąc o „zawieszeniu” komputera - jeśli powtórzyłbyś to, by powiedzieć „uczynić komputer bezużytecznym”, to tak. Z pewnością wystarczy jedno zbłąkane polecenie - moment, w którym nie myślisz jasno o tym, co robisz, podobnie jak wtedy, gdy mówisz bezmyślnie, a obrażenia mogą być ogromne i niemal natychmiastowe. Klasyczny przykład:

$ sudo rm -rf /

Jeśli pozwolisz, aby to polecenie działało nawet przez jedną sekundę, może to zniszczyć wystarczającą ilość systemu, aby uniemożliwić jego uruchomienie i być może spowodować nieodwracalną utratę danych. Nie rób tego

Załóżmy, że nie wiesz, co robisz i próbujesz wykonać kopię zapasową dysku twardego

dd if=/dev/disk1 of=/dev/disk2 

Cóż, jeśli je pomieszasz (zmień czy i nie), to zastąpi świeże dane starymi danymi, bez zadawania pytań.

Podobne pomyłki mogą się zdarzyć w przypadku narzędzi archiwalnych. I szczerze mówiąc z większością narzędzi linii poleceń.

Jeśli potrzebujesz przykładu pomieszania jednej postaci, który spowoduje awarię systemu, zapoznaj się z tym scenariuszem: Chcesz przenieść wszystkie pliki z bieżącego katalogu do innego:

 mv -f ./* /path/to/other/dir

Zaakceptujmy fakt, że nauczyłeś się używać ./do oznaczania bieżącego katalogu. (Robię) Cóż, jeśli pominiesz kropkę, zacznie przenosić wszystkie twoje pliki. W tym pliki systemowe. Masz szczęście, że tego nie sudo. Ale jeśli gdzieś przeczytasz, że używając 'sudo -i' nigdy nie będziesz musiał pisać w sudo, jesteś zalogowany jako root. A teraz twój system zjada się na twoich oczach.

Ale znowu myślę, że takie rzeczy jak nadpisywanie moich cennych plików kodu śmieciami, ponieważ pomieszałem jeden znak lub ponieważ pomieszałem kolejność parametrów, to większy problem.

Powiedzmy, że chcę sprawdzić kod asemblera generowany przez gcc:

gcc -S program.c > program.s

Załóżmy, że mam już program.s i używam uzupełniania TAB. Spieszy mi się i dwukrotnie zapominam o TAB:

gcc -S program.c > program.c

Teraz mam kod asemblera w moim programie.c i nie ma już kodu c. Dla niektórych jest to co najmniej prawdziwe niepowodzenie, ale dla innych jest to czas od początku do zera.

Myślę, że to one spowodują prawdziwą „szkodę”. Nie obchodzi mnie to, czy mój system się zawiesi. Zależy mi na utracie moich danych.

Niestety są to błędy, które należy popełnić, dopóki nie nauczysz się korzystać z terminala z zachowaniem odpowiednich środków ostrożności.

Wywoływanie paniki z jądra jest bardziej podobne do zawieszania się niż inne odpowiedzi, które do tej pory widziałem:

sudo dtrace -w -n "BEGIN{ panic();}"

(kod pobrany tutaj, a także znaleziony we własnej dokumentacji Apple )

Możesz także spróbować:

sudo killall kernel_task

Nie sprawdziłem, czy drugi tam naprawdę działa (i nie zamierzam tego robić, ponieważ mam teraz trochę pracy).

Nowoczesne macOS sprawia, że naprawdę trudno jest zawiesić komputer jako nieuprzywilejowany użytkownik (tj. Bez użycia sudo), ponieważ systemy UNIX są przeznaczone do obsługi tysięcy użytkowników, nie pozwalając żadnemu z nich złamać całego systemu. Na szczęście zazwyczaj będziesz musiał zostać poproszony, zanim zrobisz coś, co zniszczy Twoją maszynę.

Niestety ochrona ta dotyczy tylko samego systemu. Jak pokazuje xkcd, istnieje wiele rzeczy, na których Ci zależy, które nie są chronione przez integralność systemu, uprawnienia roota lub monity o hasło:

Istnieje więc mnóstwo rzeczy, które możesz wpisać, które zniszczą twoje konto użytkownika i wszystkie twoje pliki, jeśli nie będziesz ostrożny. Kilka przykładów:

• rm -rf ${TEMPDIR}/*. Wydaje się to całkowicie uzasadnione, dopóki nie uświadomisz sobie, że zmienna środowiskowa jest napisana TMPDIR. TEMPDIRjest zwykle nieokreślony, co czyni to rm -rf /. Nawet bez sudotego z radością usunie wszystko, do czego masz uprawnienia do usuwania, co zwykle obejmuje cały folder domowy. Jeśli pozwolisz, aby działało to wystarczająco długo, spowoduje to uszkodzenie dowolnego dysku podłączonego do twojego komputera, ponieważ zwykle masz do nich uprawnienia do zapisu.
• find ~ -name "TEMP*" -o -print | xargs rm. findzwykle zlokalizuje pliki spełniające określone kryteria i wydrukuje je. Bez -otego robi to, czego można się spodziewać i usuwa każdy plik zaczynający się od TEMP*( o ile nie ma spacji w ścieżce ). Ale -ooznacza „lub” (nie „wyjście”, jak ma to miejsce w przypadku wielu innych poleceń!), Powodując, że to polecenie faktycznie usuwa wszystkie pliki. Porażka.
• ln -sf link_name /some/important/file. Czasem dostaję błędną składnię tego polecenia i raczej chętnie nadpisze twój ważny plik bezużytecznym dowiązaniem symbolicznym.
• kill -9 -1 zabije każdy z twoich programów, wylogowując cię dość szybko i prawdopodobnie powodując utratę danych.

Kolejnym, co możesz zrobić (wcześniej przez pomyłkę):

sudo chmod 0 /

Spowoduje to, że cały system plików (co oznacza wszystkie polecenia i programy) będzie niedostępny ... z wyjątkiem użytkownika root. Oznacza to, że musisz zalogować się bezpośrednio jako użytkownik root i przywrócić system plików, ALE nie możesz uzyskać dostępu do sudopolecenia (ani żadnego innego polecenia, jeśli o to chodzi). Możesz przywrócić dostęp do poleceń i plików, uruchamiając system w trybie pojedynczego użytkownika, montując i przywracając system plików chmod 755 /.

Jeśli zostanie to wykonane rekurencyjnie, chmod -R 0 /spowoduje to, że system będzie bezużyteczny. Właściwą poprawką w tym momencie jest użycie Narzędzia dyskowego z partycji odzyskiwania do naprawy uprawnień do dysku . Lepiej jest przywrócić migawkę lub kopię zapasową systemu plików, jeśli uruchomiono ją rekurencyjnie.

Odpowiedzi na to połączenie sudonależy uznać za nieprawidłowe. Zakładają one już dostęp administracyjny do systemu.

Spróbować perl -e 'exit if fork;for(;;){fork;}'. OSX może mieć teraz pewne zabezpieczenia przed tym. Jeśli pojawi się bańka jabłkowa z pytaniem, czy chcesz zakończyć aplikację Terminal i podprocesy, jesteś (prawie) dobry.

while true ; do cat /dev/zero > /dev/null & donejest również bardzo przydatny, szczególnie. jeśli nie masz perl.

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & donezrobi tylko zabawny mały test obciążenia procesora. Bardzo dobrze sprawdza się, czy radiator i wentylator są na równi.

Jasne, upewnij się, że masz kopię zapasową i zapisz wszystkie pliki, na których Ci zależy, a następnie wpisz halt

Zakładając, że użyjesz wtedy sudoroota, Mac ulegnie awarii.

Największe ryzyko z linii poleceń stanowi utrata danych. Interfejs macOS został zaprojektowany przez dziesięciolecia, aby nie zaskakiwać ludzi i niszczyć ich danych, ustawień lub aplikacji. Interfejs graficzny macOS istnieje również w celu usunięcia krzywej uczenia się (stromej) do bycia bezpiecznym i opanowania skryptowania powłoki.

Tracisz te zabezpieczenia, dlatego ostrzegam ludzi, zaczynając od aplikacji terminalowej lub ssh. Jeśli masz kopię zapasową, o której wiesz, że działa i masz czas i pewność / umiejętności, aby wykonać przywracanie, powinieneś zanurkować, uczyć się, a nawet zepsuć.

sudo kill -9 -1  

Przypadkowo wykonałem kill -9 -1skrypt w perlu, działając jako root. To było tak szybkie, jak pociągnięcie za przewód zasilający. Po ponownym uruchomieniu serwer sprawdził system plików i kontynuował prawidłowe działanie.

Nigdy nie próbowałem tego sudo kill -9 -1polecenia w wierszu polecenia. Może nie działać, ponieważ identyfikator procesu „-1” oznacza „zabij wszystkie procesy należące do grupy procesów wywołującego”.

Nie jestem pewien, czy w przypadku sudo oznacza to także init i wszystkie rzeczy związane z jądrem ... Ale jeśli jesteś rootem, na kill -9 -1pewno natychmiast się zatrzyma - tak jak pociągnięcie za przewód zasilający. Nawiasem mówiąc - nic nie pojawi się w plikach dziennika, ponieważ to polecenie jest najszybszym zabójcą na zachodzie!

Właściwie, aby się zregenerować, poszedłem do naszych administratorów i powiedziałem im, co zrobiłem. Zrobili twardy restart, ponieważ nie było sposobu, aby zalogować się na tym serwerze (RHEL6).

A kill -9 -1jako root zabija każdy proces, który działa jako root. To znaczy sshd. Wylogowało mnie to natychmiast i uniemożliwiło każdemu ponowne zalogowanie. Wszelkie procesy rozpoczęte przez init - w tym init zostały zabite, chyba że zmieniły UID lub GID. Nawet logowanie za pomocą konsoli szeregowej nie było już możliwe. ps -eaf | grep rootpokazuje niektóre fantazyjne procesy, które, jeśli zareagują na SIGKILL w sposób domyślny, prawie przestaną nawet podstawowe zapisywanie na HD.

Nie spróbuję tego teraz na moim laptopie :-) Nie jestem wystarczająco ciekawy, aby dowiedzieć się, czy kill -9 165([ext4-rsv-convert]) naprawdę przestałby pisać na HD.

Tak, możesz całkowicie zniszczyć swój system. Przypadkowe zrobienie czegoś z sudouprawnieniami to jeden z opublikowanych przykładów, niezależnie od tego, czy zapomina się kilku znaków, które instruują terminal, aby zrobił coś zupełnie innego niż zamierzałeś. rming /zamiast /tmp/\*jest tylko 5 znakami różnicy. Umieszczenie miejsca w niewłaściwym miejscu może również zrobić coś zupełnie innego. Innym razem, pozornie dobre znaczenie instrukcji mogło zaciemnić do niej złośliwy kod. Niektóre osoby w Internecie są bardzo dobre w zaciemnianiu kodu.

Istnieją również polecenia, które za pomocą html mogą mieć rozmiar czcionki zero, więc coś całkowicie nieszkodliwego, po skopiowaniu do schowka, może w rzeczywistości instalować czyjąś repozytorium git jako zaufane źródło i pobierać złośliwe oprogramowanie.

Są też polecenia, które możesz uruchomić, które otwierają cię do wykorzystania, lub które mogą być doskonale przeznaczone, ale usuwają ważne pliki lub programy lub powodują uszkodzenie dysku. W rzeczywistości niepoprawne użycie narzędzi może zrobić coś tak podstawowego, jak przypadkowe zapisanie sektora rozruchowego, dysku lub wielu innych problemów.

Przykładem czegoś mniej destrukcyjnego, co nie zostało opublikowane, jest otwieranie plików binarnych vi. Jeśli kiedykolwiek spróbowałeś, będziesz wiedział, że może zepsuć twój terminal do tego stopnia, że ​​będzie bezużyteczny, dopóki nie będzie reset.

Alternatywnie istnieją polecenia, które spowodują zapadnięcie się komputera, takie jak:

yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & 

Możesz spróbować tego, nie spowoduje to obrażeń, ale spowoduje to zapchanie procesora i będziesz musiał zabić każdy proces, który pojawiłeś się.

Biorąc to pod uwagę, w obliczeniach ogólnie przyjmuje się, że nie można zrobić omletu bez rozbicia kilku jajek. Powinieneś zachować ostrożność na terminalu, ale jedynym sposobem na lepsze wykorzystanie systemu operacyjnego jest nauka i praktyka.

Jestem tylko początkującym bash, ale możesz ustawić chwilę True; wykonać polecenie; gotowy; Większość ludzi spróbuje Ctrl + C, który zatrzyma polecenie, a nie proces zewnętrzny (ctrl + Z, które następnie należy zabić). Wydaje mi się, że jeśli polecenie jest ciężką operacją, taką jak pomnożenie dużej liczby do ich własnej mocy, mogłoby to zepsuć twoje zasoby. Ale w rzeczywistości współczesne systemy operacyjne są zwykle chronione przed takim bałaganem.

Z pewnością nadal możesz spowodować awarię systemu, używając poleceń wprowadzonych w terminalu.

Z biegiem lat staje się coraz trudniej prawdopodobnie ze względu na wszelkiego rodzaju ograniczenia i zastosowane środki ochronne, ale jak mówi prawo Murphy'ego: „Nic nie jest niezawodne dla wystarczająco zdolnego głupca”.

„Bomby widelcowe” i wszystkie te rm -rfskrypty dla dzieciaków są od dawna znane w systemie UNIX. W systemie Mac OS X możesz czerpać więcej radości, korzystając z części podsystemu GUI ( WindowServeraby wspomnieć) lub czegoś w rodzaju zapory ogniowej OpenBSD, znanej również pod nazwą PFinżynierów Apple, ale nigdy nie udało się jej zaktualizować od czasu jej stanu z 2008 roku. PFdziała w jądrze więc kiedy łapie dziwactwo nadszedł czas Jabłko mówi, „ Ci ponownym uruchomieniu komputera z powodu paniki” lub rzeczy jak ta.

Najgorsze jest to, że nigdy nie możesz mieć pojęcia, gdzie pan-n-dlaczego wpadł w panikę - ponieważ Apple nie zapewnia żadnych znaczących śladów stosu; możesz mieć tylko liczbę szesnastkową adresów zwrotnych ramki stosu.

Trochę dwuznaczne jest to, co rozumiesz przez „awarię” komputera ... i nie ma na to ostatecznej poprawnej odpowiedzi, chociaż w innych odpowiedziach znajdują się przydatne przykłady. Ponieważ twoje pytanie jest bardziej dwuznaczne i ogólne, chciałbym skoncentrować się na naturze pytania i udzielić bardziej ogólnej odpowiedzi.

Ludzie, którzy nie rozumieją terminala, często boją się go używać w obawie, że mogą zepsuć swoje polecenie i spowodować awarię komputera

Myślę, że linia poleceń to obosieczny miecz, a często bardzo ostry. Jego największą siłą jest także największa słabość dla nowych użytkowników: programy CLI robią to, co mówisz, nie pytając, czy to naprawdę masz na myśli. Często nie proszą o potwierdzenie, nie zapewniają trzymania za rękę ani interaktywnej pomocy, a ich opcje są krótkie, często zwięzłe, czasem mylące ciągi tekstowe. Zauważ, że są one ogólnie bardzo dobrze udokumentowane, wystarczy przeczytać instrukcję (prawie zawsze man <command you are about to run>) i poświęcić czas na zrozumienie, co zrobi linia poleceń, którą zamierzają uruchomić.

Ten tryb działania jest potężny - oznacza to, że doświadczeni użytkownicy interfejsu CLI mogą tworzyć długie „polecenia” poleceń, które wykonują złożone zadania za pomocą pojedynczych poleceń. Wynika to z faktu, że zadanie nie pyta „Jesteś pewien?” na każdym kroku robi to, co zostało powiedziane. Ale dla użytkownika, który nie zna tego trybu i jest przyzwyczajony do GUI, w którym pomoc online jest dostępna za jednym kliknięciem , jest to nieznane i przerażające.

Ale czy istnieją polecenia, które spowodują awarię komputera?

Czy możesz „zawiesić” komputer przy użyciu interfejsu CLI? Może. Z pewnością możesz spowodować utratę danych, jeśli niewłaściwie użyjesz niszczącego polecenia. Np. Wiele odpowiedzi tutaj wspomina rm, polecenie, które usuwa pliki. Oczywiście za pomocą tego polecenia możesz spowodować utratę danych, do tego właśnie zostało przeznaczone to polecenie.

Jak wskazały inne odpowiedzi, możesz użyć wiersza polecenia, aby uczynić maszynę praktycznie bezużyteczną przez pewien czas: możesz zamknąć bez potwierdzenia, spowodować, że proces wykorzysta 100% dostępnych zasobów bez potwierdzenia, zabije wszystkie twoje programy lub zniszcz swój system plików. Jeśli naprawdę tego chcesz, możesz użyć interfejsu CLI, aby stworzyć rozszerzenie jądra, które powoduje, że jądro wpada w panikę (która jest najbliższa „awarii”, o której myślę).

Wiersz poleceń (dostępny przez terminal) jest potężnym narzędziem. Często szybsze jest rozwiązanie problemu za pomocą terminala niż GUI. Niektóre rozwiązania są dostępne tylko przy użyciu poleceń terminalu. Jednak kluczem do CLI jest zrozumienie . Nie wykonuj losowych poleceń widocznych online. Przeczytaj strony podręcznika i zrozum, co robią polecenia. Jeśli nie masz pewności, zapytaj kogoś lub dowiedz się więcej o poleceniu przed jego uruchomieniem.