Können Sie Terminal tatsächlich zum Absturz Ihres Computers verwenden?


48

Leute, die Terminal nicht verstehen, haben oft Angst, es zu benutzen, weil sie befehlen und ihren Computer zum Absturz bringen könnten. Diejenigen, die Terminal besser kennen, wissen, dass dies nicht der Fall ist - normalerweise gibt Terminal nur einen Fehler aus. Aber gibt es tatsächlich Befehle, die Ihren Computer zum Absturz bringen?

WARNUNG: Sie könnten Daten verlieren, wenn Sie diese eingeben oder Einfügen, insbesondere sudound rmBefehle kopieren .


Ein Typ hat versehentlich alle seine Firmencomputer in einer Zeile gelöscht. Ich habe es vor ein paar Jahren auf dieser Seite gesehen. Es war eine Fälschung, aber es konnte immer noch leicht passieren. Ich werde verlinken, wenn ich es finden kann.
Noah Cristino

7
Das Terminal ist nur eine Befehlszeilenschnittstelle zum Ausführen von Programmen. Es ist eine Alternative zu einer grafischen Benutzeroberfläche . Sie können von beiden Programmen aus beliebige Programme ausführen. Ihre Frage ergibt daher wenig Sinn. Sie sollten stattdessen fragen: Können Sie Ihren Computer durch Ausführen eines Programms zum Absturz bringen?
Jamesdlin

Was meinst du mit "Absturz"? Befehle, die im Terminal ausgeführt werden, können häufig leistungsstark sein und werden im Gegensatz zu den meisten Mac OS X-GUI-Befehlen häufig "das tun, was Sie sagen und nicht das, was Sie meinen", ohne danach zu fragen. Wenn Sie dies jedoch nicht absichtlich versuchen , ist es unwahrscheinlich, dass die Maschine abstürzt . (Ich kann mir jedoch einige Möglichkeiten vorstellen, dies absichtlich zu tun)
Josh

1
Das Einfügen von Befehlen aus dem Internet kann sehr gefährlich sein . Unabhängig von der Möglichkeit, Ihre Maschine aufzuhängen. Das Eingeben von Befehlen, die Sie zumindest vage verstehen, sollte jedoch nicht gefährlich sein. Ansonsten viele Möglichkeiten, Ihren Computer zu verschrauben. Es ist wie das Klicken auf zufällige Systemkonfigurationseinstellungen in der GUI, aber in der GUI sind zumindest die Möglichkeiten eingeschränkter. Es besteht die Gefahr des Einfügens von Befehlen. Der visuell kopierte Text kann sich vom tatsächlich kopierten Text unterscheiden. Daher können böswillige Befehle vermischt werden.
Akostadinov

Antworten:


51

Eine Möglichkeit, einen Computer zum Absturz zu bringen, besteht darin, eine sogenannte Gabelbombe auszuführen .

Sie können es auf einem Unix-System ausführen, indem Sie:

:(){ :|: & };:

Es ist ein Befehl, der rekursiv Prozesse erzeugt, bis das Betriebssystem so ausgelastet ist, dass es auf keine Aktion mehr reagiert.


49
@bunyaCloven Wenn ich Ihren Befehl richtig verstehe, ist es ein Befehl , alle Ordner ohne Aufforderung zu entfernen , was sehr gefährlich ist, wenn es funktioniert . Ich wünschte, Sie hätten eine Warnung dazu geschrieben.
Andrew T.

80
@AndrewT. Die Leute sollten nicht einfach willkürlich Befehle eingeben, die sie im Internet gefunden haben. (Insbesondere diejenigen in einem Thread namens "Können Sie Ihren Computer über Terminal zum Absturz bringen")
John Hamilton

34
Das OP bat um einen Absturz des Terminals, nicht um ein Abwischen.
Piersb

16
Die Gabelbombe fügt unter Mac OS X tatsächlich nur minimalen Schaden zu, da sie Obergrenzen für die Anzahl der Prozesse hat.
GDP2

7
@bunyaCloven Ersetzen Sie die ;durch eine &und Sie können alle Dateien und die Gabelbombe gleichzeitig entfernen und sehen, welche das System zuerst kaputt macht!
Muzer

41

Sie sind sich nicht sicher, was Sie mit "Absturz" des Computers meinen - wenn Sie den Begriff "Computer unbrauchbar machen" umformulieren würden, dann ja. Mit Sicherheit ist nur ein einziger Streubefehl erforderlich - nur ein Moment, in dem Sie nicht klar darüber nachdenken, was Sie tun, ähnlich wie wenn Sie ohne nachzudenken sprechen, und der Schaden kann immens und fast unmittelbar sein. Das klassische Beispiel:

$ sudo rm -rf /

Wenn Sie diesen Befehl nur eine Sekunde lang ausführen, kann dies dazu führen, dass Ihr System nicht mehr bootfähig ist und möglicherweise irreversible Daten verloren gehen. Tu es nicht.


2
Und nur um zu erklären, warum ich die Neuphrase klären wollte ... um den Computer im herkömmlichen Sinne zum Absturz zu bringen - um ihn zum Absturz zu bringen - müsste man der CPU genügend Arbeit geben, damit sie nicht mehr reagieren kann zeitnah zu anderen Jobs ... wie zum Beispiel das Aktualisieren der Grafiken und das Bewegen des Cursors. Ich bin sicher, dass es einen Weg gibt, dies von der Kommandozeile aus zu tun.
Harv

6
@DonielF -rbedeutet, Dateien in einem Verzeichnis rekursiv zu löschen. -fbedeutet "erzwingen" wie in "Keine Bestätigung anfordern", unabhängig von den Berechtigungen einer bestimmten Datei. /ist das Stammverzeichnis des Dateisystems, was bedeutet, dass alles und jedes zerstört wird, mit Ausnahme einiger spezieller Dateien, die sich nicht wie typische Dateien verhalten. Außerdem fällt es Ihnen ziemlich schwer, einen kurzen Befehl zu finden, der Ihr System ohne Root- / Administratorrechte zum Absturz bringt.
GDP2

11
Ich habe es vor rm -rf /einiger Zeit versucht und rmgesagt, wenn Sie root entfernen möchten, dann verwenden Sie das eine oder andere Flag. Es gingen keine Daten verloren. Es scheint, als gäbe es jetzt einen Sicherheitsschutz gegen blindes Laufen rm -rf /.
Alexyorke

27
- no-preserve-root flag ist seit 2006 erforderlich, damit dies wie beabsichtigt
funktioniert

6
Hier ist ein Fall aus der realen Welt, in dem dies tatsächlich passiert ist - ein Fall , der einem legalen Fall rm -rf sehr ähnlich ist und der wirklich schief gelaufen ist: /
mgarciaisaia

30

Angenommen, Sie wissen nicht, was Sie tun und versuchen, eine Sicherungskopie einer Festplatte zu erstellen

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

Nun, wenn Sie diese verwechseln (wenn und von wechseln), werden die neuen Daten mit alten Daten überschrieben, ohne dass Fragen gestellt werden.

Ähnliche Verwechslungen können bei Archiv-Utils auftreten. Und ehrlich gesagt mit den meisten Befehlszeilenprogrammen.

Wenn Sie ein Beispiel für einen Ein-Zeichen-Mix wünschen, der Ihr System zum Absturz bringt, sehen Sie sich dieses Szenario an: Sie möchten alle Dateien im aktuellen Verzeichnis in ein anderes verschieben:

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

Nehmen wir an, dass Sie gelernt haben, ./das aktuelle Verzeichnis zu bezeichnen. Wenn Sie den Punkt weglassen, werden alle Ihre Dateien verschoben. Einschließlich Ihrer Systemdateien. Du hast Glück, dass du das nicht getan hast. Aber wenn Sie irgendwo lesen, dass Sie mit 'sudo -i' nie wieder sudo eingeben müssen, sind Sie jetzt als root angemeldet. Und jetzt frisst sich Ihr System vor Ihren Augen.

Aber wieder denke ich, dass Dinge wie das Überschreiben meiner wertvollen Codedateien mit Müll, weil ich ein Zeichen durcheinander gebracht habe oder weil ich die Reihenfolge der Parameter vertauscht habe, schwieriger ist.

Angenommen, ich möchte den Assembler-Code überprüfen, den gcc generiert:

gcc -S program.c > program.s

Angenommen, ich hatte bereits ein Programm.s und verwende die TAB-Vervollständigung. Ich habe es eilig und vergesse zweimal TAB:

gcc -S program.c > program.c

Jetzt habe ich den Assembler-Code in meinem Programm.c und keinen C-Code mehr. Das ist zumindest für einige ein echter Rückschlag, für andere jedoch ein Neustart.

Ich denke, das sind diejenigen, die echten "Schaden" anrichten. Es ist mir egal, ob mein System abstürzt. Ich würde mich darum kümmern, dass meine Daten verloren gehen.

Leider sind dies die Fehler, die gemacht werden müssen, bis Sie lernen, das Terminal mit den richtigen Vorsichtsmaßnahmen zu verwenden.


16
Ihr letzter Punkt ist einer von vielen Gründen, warum jeder die Versionskontrolle verwenden sollte
Darren H

4
Ich habe einmal ein Programm zerstört, an dem ich gerade gearbeitet habe gcc program.c -o program.c. Danach habe ich gelernt, die Versionskontrolle religiös anzuwenden.
nneonneo

2
Die bisher beste Antwort ist das Posten von legitim aussehenden Befehlen, die das Ergebnis eines einfachen Tippfehlers sein könnten und dennoch zu einem großen Schaden führen können.
Gaazkam

1
"Jetzt habe ich den Assembler-Code in meinem Programm.c" Nein. Du hast nichts. Die Umleitung hat die Datei abgeschnitten, bevor GCC sie überhaupt geöffnet hat.
muru

1
Oh man, ich bin wirklich froh, dass sie diese Verbesserung der Benutzeroberfläche in GCC hinzugefügt haben. Es ist schon eine Weile her, seit ich meinen letzten Fehler gemacht habe, aber es ist schön zu sehen, dass ich ein bisschen Schutz vor dem nächsten Mal haben werde.
Nneonneo

28

Eine Kernel-Panik auszulösen ist eher ein Absturz als die anderen Antworten, die ich bisher hier gesehen habe:

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

(Code von hier übernommen und auch in Apples eigener Dokumentation zu finden )

Sie könnten auch versuchen:

sudo killall kernel_task

Ich habe nicht überprüft, ob der zweite tatsächlich funktioniert (und ich habe auch nicht vor, da momentan noch einige Arbeiten offen sind).


2
Habe gerade den zweiten in einer 10.12.3 VM ausprobiert und es steht nur:No matching processes were found
Alexander O'Mara

3
Auch der erste scheint nicht zu funktionieren, zumindest wenn SIP aktiviert ist,dtrace: system integrity protection is on, some features will not be available dtrace: description 'BEGIN' matched 1 probe dtrace: could not enable tracing: Permission denied
Alexander O'Mara

@ AlexanderO'Mara Nicht sehr überrascht von deinen Ergebnissen beim zweiten Befehl; Ich dachte mir, dass Mac OS X es Ihnen nicht erlauben würde, den Kernelprozess auf diese Weise herunterzufahren. Die Ergebnisse für den ersten Befehl sind ebenfalls zu erwarten, wie dies dtracedurch SIP effektiv neutralisiert wurde.
GDP2

1
kernel_taskist kein normaler Prozess. Es ist unsterblich; Es kann nur durch einen eigenen Fehler getötet werden (und das würde als KP bezeichnet und bringt die gesamte Maschine zum Erliegen). kernel_taskDie PID von ist nominell 0, aber wenn Sie diese an den kill(pid, sig)Syscall übergeben, wird auf der Manpage angezeigt, dass If pidgleich 0 sigist und an jeden Prozess in der Prozessgruppe des aufrufenden Prozesses gesendet wird. . Sie können also einfach kein kernel_taskSignal senden .
Iwillnotexist Idonotexist

@IwillnotexistIdonotexist Ja, ich dachte, so viel wäre der Fall. danke aber für die info. Gute Sachen im Kopf zu haben.
GDP2

19

Modernes macOS macht es wirklich schwierig, Ihren Computer als nicht privilegierter Benutzer zum Absturz zu bringen (dh ohne ihn zu verwenden sudo), da UNIX-Systeme dazu gedacht sind, Tausende von Benutzern zu behandeln, ohne dass einer von ihnen das gesamte System beschädigen kann. Glücklicherweise müssen Sie normalerweise dazu aufgefordert werden, bevor Sie etwas tun, das Ihre Maschine zerstört.

Leider gilt dieser Schutz nur für das System selbst. Wie xkcd zeigt, gibt es viele Dinge, die Sie interessieren und die nicht durch Systemintegritätsschutz, Root-Berechtigungen oder Passwortabfragen geschützt sind:

XKCD 1200

Es gibt also Unmengen von Dingen, die Sie eingeben können und die Ihr Benutzerkonto und alle Ihre Dateien zerstören, wenn Sie nicht vorsichtig sind. Einige Beispiele:

  • rm -rf ${TEMPDIR}/*. Dies scheint völlig vernünftig, bis Sie feststellen, dass die Umgebungsvariable geschrieben ist TMPDIR. TEMPDIRist in der Regel undefiniert, was das macht rm -rf /. Auch ohne sudowird alles, für das Sie Löschberechtigungen haben, entfernt, was normalerweise Ihren gesamten privaten Ordner umfasst. Wenn Sie dies lange genug laufen lassen, wird auch jedes an Ihren Computer angeschlossene Laufwerk beschädigt, da Sie normalerweise über Schreibberechtigungen für diese verfügen.
  • find ~ -name "TEMP*" -o -print | xargs rm. findfindet normalerweise Dateien, die bestimmten Kriterien entsprechen, und druckt sie aus. Ohne das -otut dies, was Sie erwarten, und löscht jede Datei, die mit beginnt TEMP*( solange Sie keine Leerzeichen im Pfad haben ). Das -obedeutet aber "oder" (nicht "ausgeben" wie bei vielen anderen Befehlen!), Wodurch dieser Befehl tatsächlich alle Ihre Dateien löscht. Schade.
  • ln -sf link_name /some/important/file. Ich verstehe die Syntax für diesen Befehl gelegentlich als falsch und er überschreibt Ihre wichtige Datei mit einem unnützen symbolischen Link.
  • kill -9 -1 tötet jedes Ihrer Programme, meldet Sie ziemlich schnell ab und verursacht möglicherweise Datenverlust.

3
FYI (für andere dies lesen) findhat ein -deleteArgument , das ist viel sicherer als kochend zuxargs rm
Josh

Ist modernes MacOS wirklich sturzsicherer? Die meisten dieser Systeme sind für einen einzelnen Benutzer. Haben sie wirklich vernünftige Höchstwerte? Können Sie eine Referenz angeben?
user2497

1
Sie, ln -sf
ausgerechnet

1
@Josh: Danke für den Hinweis. Und im Allgemeinen sollte man verwenden find -print0 | xargs -0, um seltsame Zeichen in Dateinamen sicher zu behandeln.
Nneonneo

1
Einverstanden. Nützlicherer xargs-Rat: Verwenden Sie <whatever> | xargs echo <something>zunächst, um eine Vorschau der Befehle anzuzeigen, die xargs tatsächlich ausführen wird. xargs ist ein großartiges Beispiel dafür, warum die CLI so leistungsfähig ist: Sie können mit vielen, vielen Elementen gleichzeitig arbeiten, ohne lästige Bestätigung und Handhaltung.
Josh

16

Ein anderes, was Sie tun können (was ich versehentlich getan habe), ist:

sudo chmod 0 /

Dadurch kann auf Ihr gesamtes Dateisystem (dh auf alle Befehle und Programme) nur vom Root-Benutzer zugegriffen werden. Dies bedeutet, dass Sie sich direkt als Root-Benutzer anmelden und das Dateisystem wiederherstellen müssen, ABER Sie können nicht auf den sudoBefehl (oder einen anderen Befehl) zugreifen . Sie können den Zugriff auf Befehle und Dateien wiederherstellen, indem Sie im Einzelbenutzermodus booten und das Dateisystem mit bereitstellen und wiederherstellen chmod 755 /.

Wenn dies rekursiv mit chmod -R 0 /erfolgt, wird das System dadurch unbrauchbar. Die richtige Lösung zu diesem Zeitpunkt ist die Verwendung des Festplatten-Dienstprogramms von der Wiederherstellungspartition, um Festplattenberechtigungen zu reparieren . Möglicherweise ist es besser, nur einen Snapshot oder eine Sicherung Ihres Dateisystems wiederherzustellen, wenn dies rekursiv ausgeführt wurde.


8
"Sie können das Problem beheben, indem Sie ... chmod 755 /" - Nein, können Sie nicht. Viele Dateien erfordern andere Berechtigungen als 755, entweder aus Sicherheitsgründen oder um überhaupt zu funktionieren. chmod 755 /wird Ihr System unsicher und auf subtile Weise kaputt machen. Die einzige vollständige Wiederherstellung chmod 0 /erfolgt durch Snapshot-Wiederherstellung, Backup-Wiederherstellung und / oder Neuinstallation.
Marcelm

2
@ marcelm Guter Punkt. Mein Vorschlag war nur, den Zugriff auf Befehle wiederherzustellen, nicht als dauerhafte Lösung. Ich habe meine Antwort aktualisiert, um dies widerzuspiegeln. Soweit ich weiß, ist chmod nur dann rekursiv, wenn Sie das -RFlag verwenden. Ich dachte also, die Berechtigungen von Unterverzeichnissen wären nicht betroffen?
musicman523

5
@marcelm Sie haben Recht, aber der angezeigte Befehl ist nicht rekursiv , sondern nur /betroffen.
Andrea Lazzarotto

Ich war einmal sudo chmod -R 700 /ein neuer Computer und dachte, es wäre viel sicherer, wenn ich das täte. Überraschenderweise bootete es und endete mit einer leeren Menüleiste und einem leeren Desktop. Nichts anderes funktionierte, aber die Festplatten-Dienstprogramm-Wiederherstellungsberechtigungen der Wiederherstellungspartition haben tatsächlich fast alles richtig gemacht!
Nneonneo

2
Das Dienstprogramm @marcelm Disk verfügt über die Option "Berechtigungen reparieren", die dies ohne vollständige Systemwiederherstellung korrigieren sollte
Josh

10

Antworten, die angerufen werden, sudosollten als ungültig betrachtet werden. Diese übernehmen bereits den administrativen Zugriff auf das System.

Versuchen Sie es perl -e 'exit if fork;for(;;){fork;}'. OSX hat möglicherweise jetzt einen gewissen Schutz dagegen. Wenn eine Apfelblase auftaucht und fragt, ob Sie Terminal-App und Subprozesse beenden möchten, sind Sie (fast) gut.

while true ; do cat /dev/zero > /dev/null & doneist auch sehr praktisch, esp. wenn du nicht hast perl.

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & doneIch werde nur einen lustigen kleinen CPU-Belastungstest machen. Sehr gut geeignet, um zu überprüfen, ob Ihr Kühlkörper und Ihr Lüfter den Anforderungen entsprechen.


Dies wird als Gabelbombe bezeichnet und macht das System wahrscheinlich unbrauchbar (kann als "Absturz" angesehen werden), verursacht jedoch wahrscheinlich keinen dauerhaften Schaden. Aber es ist böse!
Josh

@Josh "wird aber wahrscheinlich keinen dauerhaften Schaden anrichten" Mit Ausnahme von derzeit geöffneten, nicht gespeicherten Arbeiten.
Reirab

@reirab Josh fügte seiner Aussage das Allheilmittel "wahrscheinlich" hinzu. Aber MacOS ist jetzt hauptsächlich zum Bearbeiten von Fotos und Videos gedacht. Verfügen die Adobe-Programme nicht über eine automatische Speicherung?
user2497

1
Außerdem ist nicht gespeicherte Arbeit immer gefährdet, bis sie gespeichert wird. Wenn Ihr Computer unbrauchbar gemacht wird, können Sie nichts speichern, was Sie geöffnet haben :)
Josh

@ Josh MacOS ist so einfach, Dinge zu speichern. Es ist immer always-S. Du hättest nicht 'wahrscheinlich' schreiben
sollen

7

Stellen Sie sicher, dass Sie eine Sicherungskopie haben, und speichern Sie alle Dateien, die Sie interessieren. Geben Sie dann Folgendes ein halt

Vorausgesetzt, Sie sind sudoals Root angemeldet, stürzt der Mac ab.

Das größte Risiko von der Kommandozeile ist Datenverlust. Die Benutzeroberfläche von macOS wurde über Jahrzehnte hinweg so konzipiert, dass sie Menschen nicht überrascht und ihre Daten, Einstellungen oder Apps nicht zerstört. Die grafische Benutzeroberfläche von macOS bietet auch die Möglichkeit, die Lernkurve (eine steile) zu überwinden, um sicher zu sein und Shell-Skripte zu beherrschen.

Sie verlieren diesen Schutz, weshalb ich die Leute warne, die mit der Terminal-App oder ssh beginnen. Wenn Sie eine Sicherungskopie haben, von der Sie wissen, dass sie funktioniert, und die Zeit und das Vertrauen / die Fähigkeit haben, eine Wiederherstellung durchzuführen, sollten Sie eintauchen und lernen und sogar Dinge brechen.


3
Sie sagten: "... und brechen sogar Dinge." Dies ist ein guter Anwendungsfall, um riskante Dinge in einer virtuellen Maschine zu erledigen. :)
user3439894

1
Wie wird dieser Absturz? Das System wird sofort heruntergefahren. Sogar Kernel-Puffer werden geleert, sodass kein (gespeicherter) Datenverlust auftritt. developer.apple.com/legacy/library/documentation/Darwin/…
Josh

7
sudo kill -9 -1  

Ich habe versehentlich kill -9 -1ein Perl-Skript ausgeführt, das als root ausgeführt wurde. Das war so schnell wie das Ziehen des Netzkabels. Beim Neustart führte der Server eine Dateisystemprüfung durch und lief ordnungsgemäß weiter.

Ich habe diesen sudo kill -9 -1Befehl nie in der Befehlszeile ausprobiert . Möglicherweise funktioniert es nicht, da die Prozess-ID "-1" "alle Prozesse beenden" bedeutet, die zur Prozessgruppe des Aufrufers gehören.

Ich bin mir nicht sicher, ob mit sudo auch init und all das Kernel-Zeug gemeint ist ... Aber wenn Sie root sind, kill -9 -1machen Sie auf jeden Fall einen sofortigen Stopp - genau wie beim Ziehen des Netzkabels. Übrigens - in Logfiles wird nichts angezeigt, denn dieser Befehl ist der schnellste Killer im Westen!

Um mich zu erholen, ging ich zu unseren Sysadmins und erzählte ihnen, was ich tat. Sie haben einen harten Neustart durchgeführt, da es keine Möglichkeit gab, sich auf diesem Server anzumelden (RHEL6).

Ein kill -9 -1als root beendet jeden Prozess, der als root ausgeführt wird. Das ist zB sshd. Das hat mich sofort abgemeldet und verhindert, dass sich jemand erneut anmeldet. Alle von init gestarteten Prozesse - einschließlich init - wurden abgebrochen, es sei denn, sie haben die UID oder GID geändert. Selbst das Einloggen über die serielle Konsole war nicht mehr möglich. ps -eaf | grep rootzeigt einige ausgefallene Prozesse, die, wenn sie standardmäßig auf einen SIGKILL reagieren, selbst das grundlegende Schreiben auf HD so gut wie stoppen würden.

Ich werde das jetzt nicht auf meinem Laptop ausprobieren :-) Ich bin nicht neugierig genug herauszufinden, ob ein kill -9 165([ext4-rsv-conver]) wirklich aufhören würde, auf die HD zu schreiben.


Sie können den Kernel nicht "töten", und dies sollte nicht dazu führen, dass sich das Dateisystem eincheckt. Wie haben Sie sich von der Situation erholt? Haben Sie einen harten Neustart durchgeführt? Weil das wahrscheinlich die Ursache für die Überprüfung des Dateisystems ist :)
Josh

Ihre bearbeitete Antwort macht Sinn. Sie können initnormalerweise nicht töten , aber Sie können alle Gettys und SSH-Sitzungen töten und den Computer unbrauchbar machen. Ein Magic SysRq hätte einen sauberen Neustart ermöglichen müssen, aber es ist oft einfacher, das System aus- und wieder einzuschalten und sich auf das FS-Journal zu verlassen :)
Josh

5

Ja, Sie können Ihr System vollständig zerstören. Versehentlich etwas mit sudoPrivilegien zu tun, ist ein Beispiel, das veröffentlicht wurde, ob es ein paar Zeichen vergisst, die das Terminal anweisen, etwas völlig anderes zu tun, als Sie beabsichtigt haben. rming /statt /tmp/\*nur 5 Zeichen Unterschied. Wenn Sie ein Leerzeichen an die falsche Stelle setzen, kann dies ebenfalls zu einem völlig anderen Ergebnis führen. In anderen Fällen, in denen Anweisungen anscheinend gut verstanden werden, könnte bösartiger Code darin verschleiert sein. Einige Leute im Internet sind sehr gut darin, Code zu verschleiern.

Es gibt auch Befehle, die mit HTML auf die Schriftgröße Null gesetzt werden können. Wenn Sie also völlig harmlos in die Zwischenablage kopieren, können Sie das Git-Repo einer anderen Person als vertrauenswürdige Quelle installieren und Malware herunterladen.

Und es gibt Befehle, die Sie ausführen können, um sie auszunutzen, oder die perfekt gedacht sind, aber wichtige Dateien oder Programme entfernen oder Ihre Festplatte beschädigen. Tatsächlich kann die falsche Verwendung von Werkzeugen so grundlegende Auswirkungen haben, wie das versehentliche Überschreiben Ihres Boot-Sektors, des Kopfs Ihrer Festplatte oder vieler anderer Probleme.

Ein Beispiel für etwas weniger Destruktives, das nicht veröffentlicht wurde, ist das Öffnen von Binärdateien in vi. Wenn Sie es jemals ausprobiert haben, wissen Sie, dass es Ihr Terminal bis zu dem Punkt durcheinander bringen kann, an dem es unbrauchbar ist, bis es unbrauchbar ist reset.

Alternativ gibt es Befehle, die Ihre Maschine zum Stillstand bringen, wie zum Beispiel:

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

Du kannst es versuchen, es wird keinen Schaden anrichten, aber es wird deinen Prozessor zum Stillstand bringen und du musst jeden Prozess, den du erzeugt hast, abbrechen.

Allerdings wird beim Rechnen im Allgemeinen davon ausgegangen, dass man kein Omelett machen kann, ohne ein paar Eier zu zerbrechen. Sie sollten am Terminal vorsichtig sein, aber die einzige Möglichkeit, das Betriebssystem besser zu nutzen, besteht darin, zu lernen und zu üben.


Ihr erstes Beispiel ist kaum schädlich. Vim ist eigentlich ziemlich vernünftig beim Bearbeiten von Binärdateien. Und im schlimmsten Fall können Sie einfach das Fenster schließen. Das zweite Beispiel mit "Ja" ist ärgerlich und beansprucht einiges an Benutzer-CPU, aber das System reagiert weiterhin und Sie können das übergeordnete Terminalfenster problemlos beenden.
Nneonneo

1
Ich bin nicht einverstanden mit "Verwirren Sie Ihr Terminal, bis es unbrauchbar ist, bis Sie neu starten" - versuchen Sie reset, ein Terminal zu löschen, auf dem Binärausgabe gedruckt wurde. oder laichen Sie einfach ein neues TTY
Josh

1
Cool, nw @JFA. Eigentlich habe ich neun Jahre gebraucht, um den resetTrick zu lernen ! Für weitere Informationen: unix.stackexchange.com/questions/79684
Josh

1
@ Josh, danke dafür, es war eine große Hilfe. Es sind in der Tat viele Jahre für mich
JFA

1
@Josh Dann sollten 'stty sane ^ M' und 'tput reset' auch für dich spannend sein.
user2497

4

Ich bin nur ein Bash-Anfänger, aber Sie könnten eine Weile True setzen; do COMMAND; getan; Die meisten Benutzer würden Strg + C verwenden, um den Befehl zu stoppen, nicht den externen Prozess (Strg + Z, der dann beendet werden muss). Ich vermute, wenn ein Befehl eine schwere Operation ist, wie das Multiplizieren einer großen Anzahl mit ihrer eigenen Kraft, könnte dies mit Ihren Ressourcen zu schaffen machen. Aber in der Tat sind moderne Betriebssysteme in der Regel gegen solche Unordnung geschützt.


2
Es läuft einfach sehr schnell und bringt nichts zum Absturz. Sie müssen nur einige intensive Berechnungen durchführen, damit Sie Kernel-maxprocs nicht traurig machen. trywhile true do cat /dev/zero > /dev/null & done
user2497

Vielen Dank. Ich hätte erwartet, dass der Umgang mit großen Zahlen den Computer verlangsamt. Manchmal passierte dies mit sehr einfachen Java / Python-Programmen, die ich für maschinelles Lernen verwendete.
Ando Jurai

1
Das Cat-Null-zu-Null-Bit ist eine große Zahlenoperation, zumindest in E / A. Ich benutze eine dieser pro Kern einer CPU, um thermische Tests durchzuführen.
user2497

1
Und beendet ^C auch die while-Schleife, die sich jedoch zu schnell wiederholt, als dass der Interrupt abgefangen werden könnte. Gedrückthalten ^Ckann aus der Schleife ausbrechen. Das Schließen des Terminals wird auch :)
Josh

2
@Josh Es ist einfacher, INT zu erfassen, wenn nach der CPU-intensiven Aufgabe eine winzige Pause (z. B. Schlaf 0.1) eintritt.
user2497

3

Sicherlich können Sie mit den über Terminal eingegebenen Befehlen immer noch einen Systemabsturz verursachen.

Mit den Jahren wird es wahrscheinlich schwieriger, weil alle Arten von Grenzen und Schutzmaßnahmen angewendet werden, aber wie Murphys Gesetz besagt: "Nichts ist narrensicher für einen hinreichend fähigen Narren."

"Fork Bombs" und all das rm -rfZeug für Script-Kiddies sind altbekannte Dinge für UNIX. Mit Mac OS X können Sie mehr Spaß haben, wenn Sie Teile des GUI-Subsystems (um es WindowServerzu erwähnen) oder etwas wie die OpenBSD-Firewall verwenden PF, die Apples Ingenieure eingeführt haben, die es jedoch seit dem Stand von 2008 nie mehr geschafft haben, zu aktualisieren. PFFunktioniert im Kernel. Wenn es also merkwürdig wird, ist es an der Zeit, dass Apple Ihnen mitteilt, dass Sie den Computer aufgrund einer Panik neu gestartet haben, oder ähnliches.

Das Schlimmste daran ist, dass Sie nie eine Vorstellung davon haben können, warum es in Panik geriet - weil Apple keine aussagekräftigen Stack-Traces bereitstellt. Sie können nur hexadezimale Zahlen für die Rücksendeadressen des Stapelrahmens verwenden.


Gute Antwort und hervorragende Punkte. Ich möchte meiner Liste der besten Möglichkeiten, OS X in Panik zu versetzen, meinen persönlichen Favoriten hinzufügen, jedoch ohne ausdrückliche Bedingungen, um Dummheiten durch Drehbuchkinder zu vermeiden. Ich entlade eine für NFC relevante Kernel-Erweiterung. Funktioniert jedes Mal sofort. Man kann dies leicht in ein DOS umwandeln, indem man dies auf eine teilbare Anzahl von etwa 5 Minuten einplant. Daher wird es dann Schwanentauchen booten. Dies erfordert eine Neuinstallation des Betriebssystems, da die meisten Administratoren und sogar Techniker dies verpassen werden ....
Francis von ResponseBase

3

Es ist ein wenig mehrdeutig, was Sie unter "Absturz" Ihres Computers verstehen ... und es gibt keine endgültige richtige Antwort dafür, obwohl es in anderen Antworten einige nützliche Beispiele gibt. Da Ihre Frage mehrdeutiger und allgemeiner ist, möchte ich mich auf die Art der Frage konzentrieren und eine allgemeinere Antwort geben.

Leute, die Terminal nicht verstehen, haben oft Angst, es zu benutzen, weil sie befehlen und ihren Computer zum Absturz bringen könnten

Ich denke, die Kommandozeile ist ein zweischneidiges und oft sehr scharfes Schwert. Seine größte Stärke ist auch seine größte Schwäche für neue Benutzer: CLI-Programme tun, was Sie sagen, ohne zu fragen, ob es wirklich das ist, was Sie gemeint haben. Sie fordern oft keine Bestätigung an, bieten keine Handhaltung oder interaktive Hilfe an und ihre Optionen sind kurz, oft knapp und manchmal verwirrend. Beachten Sie, dass sie im Allgemeinen sehr gut dokumentiert sind. Sie müssen lediglich das Handbuch lesen (was fast immer der Fall ist man <command you are about to run>) und sich die Zeit nehmen, um zu verstehen, was die auszuführende Befehlszeile tun wird.

Diese Betriebsart ist leistungsstark. Erfahrene CLI-Benutzer können lange Befehls-Pipelines erstellen, die komplexe Aufgaben mit einzelnen Befehlen ausführen. Dies liegt daran, dass die Aufgabe nicht fragt, ob Sie sicher sind. Bei jedem Schritt wird das getan, was gesagt wird. Für einen Benutzer, der mit diesem Modus nicht vertraut ist und an eine Benutzeroberfläche gewöhnt ist, in der die Online-Hilfe nur einen Klick entfernt ist, ist dies jedoch ungewohnt und beängstigend.

Aber gibt es tatsächlich Befehle, die Ihren Computer zum Absturz bringen?

Können Sie Ihren Computer mit der CLI "zum Absturz bringen"? Vielleicht. Sie können mit Sicherheit Datenverluste verursachen, wenn Sie einen destruktiven Befehl falsch verwenden. ZB erwähnen viele der Antworten hier rmeinen Befehl, der Dateien löscht. Offensichtlich können Sie mit diesem Befehl Datenverluste verursachen. Dafür wurde der Befehl entwickelt.

Wie andere Antworten gezeigt haben, können Sie Ihren Computer über die Befehlszeile für einen bestimmten Zeitraum praktisch unbrauchbar machen: Sie können den Computer ohne Bestätigung herunterfahren, einen Prozess veranlassen, 100% Ihrer verfügbaren Ressourcen zu nutzen, ohne Bestätigung, alle Ihre Programme zu beenden oder zerstöre dein Dateisystem. Wenn Sie es wirklich wollten, können Sie mit der CLI eine Kernel-Erweiterung erstellen, die den Kernel in Panik versetzt (was einem "Absturz" am nächsten kommt, den ich mir vorstellen kann).

Die Befehlszeile (über das Terminal zugänglich) ist ein leistungsfähiges Werkzeug. Oft ist es schneller, ein Problem mit Terminal zu lösen als mit der GUI. Einige Lösungen sind nur mit Terminalbefehlen verfügbar. Der Schlüssel zur CLI ist jedoch das Verständnis . Führen Sie keine zufälligen Befehle aus, die Sie online sehen. Lesen Sie die Manpages und erfahren Sie, was Befehle bewirken. Wenn Sie sich nicht sicher sind, fragen Sie jemanden oder erfahren Sie mehr über einen Befehl, bevor Sie ihn ausführen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.