Un modo per bloccare un computer è eseguire una cosiddetta bomba a forcella .

Puoi eseguirlo su un sistema unix di:

:(){ :|: & };:

È un comando che genererà ricorsivamente i processi fino a quando il sistema operativo sarà così impegnato da non rispondere più a nessuna azione.

Non sei sicuro di cosa intendi per "schiantare" il computer - se vuoi riformulare la frase per dire "rendere inutilizzabile il computer", allora si. Certamente basta un unico comando di randagio: solo un momento in cui non stai pensando chiaramente a cosa stai facendo, simile a quando parli senza pensare, e il danno può essere immenso e quasi immediato. L'esempio classico:

$ sudo rm -rf /

Se si lascia eseguire quel comando anche solo per un secondo, è possibile eliminare un numero sufficiente del proprio sistema per renderlo non avviabile e, eventualmente, causare una perdita irreversibile di dati. Non farlo.

Supponiamo di non sapere cosa stai facendo e di provare a eseguire il backup di alcuni dischi rigidi

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

Bene, se li mixai (passa if e di), sovrascriverà i nuovi dati con i vecchi dati, senza fare domande.

Simili mescolamenti possono accadere con i programmi di archiviazione. E francamente con la maggior parte delle utilità della riga di comando.

Se vuoi un esempio di un missaggio di un personaggio che bloccherà il tuo sistema dai un'occhiata a questo scenario: vuoi spostare tutti i file nella directory corrente in un altro:

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

Accettiamo il fatto che hai imparato a usare ./ per indicare la directory corrente. (Lo voglio) Bene se ometti il punto, inizierà a spostare tutti i tuoi file. Compresi i file di sistema. Sei fortunato che non hai fatto questo. Ma se si legge da qualche parte che con 'sudo -i' non sarà più necessario digitare in sudo, si è effettuato il login come root ora. E ora il tuo sistema si sta mangiando davanti ai tuoi occhi.

Ma di nuovo penso che cose come la sovrascrittura dei miei preziosi file di codice con garbage, perché ho incasinato un personaggio o perché ho confuso l'ordine dei parametri, sono più problemi.

Diciamo che voglio controllare il codice assemblatore che gcc sta generando:

gcc -S program.c > program.s

Supponiamo che io abbia già un programma. Io uso il completamento del TAB. Sono di fretta e dimentico di TAB due volte:

gcc -S program.c > program.c

Ora ho il codice assembler nel mio program.c e nessun codice c più. Che è almeno una vera battuta d'arresto per alcuni, ma per gli altri è un passaggio da zero.

Penso che questi siano quelli che causeranno un vero "danno". Non mi interessa davvero se il mio sistema si arresta in modo anomalo. Mi piacerebbe che i miei dati andassero persi.

Sfortunatamente questi sono gli errori che dovranno essere fatti finché non imparerai a usare il terminale con le dovute precauzioni.

Causare un panico del kernel è più simile al crash rispetto alle altre risposte che ho visto qui finora:

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

(codice preso da qui e trovato anche nella documentazione di Apple )

Potresti anche provare:

sudo killall kernel_task

Non ho verificato che il secondo funzioni effettivamente (e non intendo, visto che attualmente ho qualche lavoro aperto).

Il macOS moderno rende veramente difficile far crashare la macchina come utente non privilegiato (cioè senza usare sudo ), perché i sistemi UNIX sono pensati per gestire migliaia di utenti senza che nessuno di essi possa rompere il intero sistema. Quindi, per fortuna, di solito devi essere richiesto prima di fare qualcosa che distrugge la tua macchina.

Sfortunatamente, tale protezione si applica solo al sistema stesso. Come illustra xkcd, ci sono molte cose a cui tu tieni a mente che non sono protette da System Integrity Protection, privilegi di root o prompt di password:

Quindi,cisonounsaccodicosechepuoiscriverechedistruggerannoiltuoaccountutenteetuttiituoifilesenonstaiattento.Alcuniesempi:

• %codice%.Questosembradeltuttoragionevole,finchénontiaccorgichelavariabiled'ambienteèscrittarm-rf${TEMPDIR}/*.TMPDIRdisolitononèdefinito,ilcherendequestoTEMPDIR.Anchesenzarm-rf/,questorimuoveràfelicementetuttociòacuihaipermessodieliminare,chedisolitoincludel'interacartellahome.Selolasciabbastanzaalungo,verràcolpitoanchequalsiasidiscocollegatoaltuocomputer,datochedisolitohaipermessidiscritturaperquesti.
• %codice%.sudonormalmentelocalizzeràifilechecorrispondonoadeterminaticriterielistamperà.Senzafind~-name"TEMP*" -o -print | xargs rm questo è quello che ti aspetteresti e cancella ogni file che inizia con find ( se non hai spazi nel percorso ). Ma, -o significa "o" (non "output" come per molti altri comandi!), Facendo sì che questo comando cancelli tutti i tuoi file. Peccato.
• %codice%. A volte capita che la sintassi di questo comando sia errata e sostituirà piuttosto felicemente il tuo file importante con un link simbolico inutile.
• TEMP* uccide tutti i tuoi programmi, ti disconnette piuttosto rapidamente e probabilmente causa la perdita di dati.

Un altro che puoi fare (che ho già fatto per errore prima) è:

sudo chmod 0 /

Questo renderà l'intero file system (che significa tutti i comandi e i programmi) inaccessibile ... tranne dall'utente root. Ciò significa che è necessario accedere direttamente come utente root e ripristinare il file system, MA non si è in grado di accedere al comando sudo (o qualsiasi altro comando, se è per questo). È possibile ripristinare l'accesso a comandi e file avviando in modalità utente singolo, montando e ripristinando il file system con chmod 755 / .

Se ciò avviene in modo ricorsivo con chmod -R 0 / , ciò renderà il sistema inutilizzabile. La corretta correzione a quel punto è di utilizzare Utility Disco dalla partizione di ripristino alle autorizzazioni del disco di riparazione . Potresti stare meglio solo per ripristinare un'istantanea o un backup del tuo file system se questo è stato eseguito in modo ricorsivo.

Le risposte che chiamano sudo dovrebbero essere considerate non valide. Questi già presuppongono accesso amministrativo al sistema.

Prova perl -e 'exit if fork;for(;;){fork;}' . OSX potrebbe avere qualche salvaguardia contro questo ora. Se è presente una bolla di mela che chiede se si desidera terminare l'applicazione e i sottoprocessi del terminale, sei (quasi) bravo.

while true ; do cat /dev/zero > /dev/null & done è anche molto utile, esp. se non hai perl .

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & done eseguirà solo un buffo test di caricamento della CPU. Ottimo per verificare se il tuo dissipatore e la ventola sono all'altezza.

Certo, assicurati di avere un backup e salva tutti i file che ti interessano, quindi digita halt

Supponendo che tu usi sudo come root, il Mac si bloccherà.

Il maggior rischio dalla riga di comando è la perdita di dati. L'interfaccia macOS è progettata per decenni per non sorprendere le persone e distruggere i loro dati o impostazioni o app. L'interfaccia grafica macOS esiste anche per rimuovere la curva di apprendimento (una ripida) per essere sicuri e padroneggiare lo scripting della shell.

Si perdono queste protezioni e questo è il motivo per cui avviso le persone che iniziano con l'app terminale o ssh. Se hai un backup che sai funzionare e hai il tempo e la sicurezza / abilità per eseguire un ripristino, allora dovresti immergerti e imparare e persino rompere le cose.

sudo kill -9 -1  

Ho eseguito accidentalmente un kill -9 -1 in uno script perl, eseguito come root. Era veloce come tirare il cavo di alimentazione. Al riavvio, il server ha eseguito un controllo del filesystem e ha continuato a funzionare correttamente.

Non ho mai provato quel comando sudo kill -9 -1 sulla riga di comando. Potrebbe non funzionare, perché l'ID di processo "-1" significa "uccidere tutti i processi che appartengono al gruppo di processi del chiamante".

Non sono sicuro, se con sudo, ciò significa anche init e tutte le cose del kernel ... Ma se sei root, kill -9 -1 farà sicuramente un arresto immediato, proprio come se tirassi il cavo di alimentazione. A proposito: niente apparirà nei file di log, perché quel comando è il killer più veloce ad ovest!

In realtà, per riprendermi, sono andato dai nostri amministratori di sistema e ho detto loro, cosa ho fatto. Hanno fatto un duro riavvio, perché non c'era modo di accedere a quel server (RHEL6).

Un kill -9 -1 come root uccide ogni processo, eseguito come root. Questo è, sshd. Questo mi ha disconnesso immediatamente e ha impedito a chiunque di accedere di nuovo. Qualsiasi processo avviato da init - incluso init è stato ucciso, a meno che non abbiano cambiato UID o GID. Non era più possibile effettuare il login attraverso la console seriale. ps -eaf | grep root mostra alcuni processi elaborati, che, se reagiscono su un SIGKILL nel modo predefinito, fermerebbero praticamente anche la scrittura di base sull'HD.

Non lo proverò ora sul mio laptop :-) Non sono abbastanza curioso di scoprirlo, se un kill -9 165 ([ext4-rsv-conver]) fermerebbe davvero la scrittura sull'HD.

Sì, puoi distruggere completamente il tuo sistema. Accidentalmente fare qualcosa con sudo privilegi è un esempio che è stato pubblicato, se si dimentica di alcuni caratteri che istruiscono il terminale a fare qualcosa di completamente diverso da quello che intendi. rm ing / invece di /tmp/\* è solo una differenza di 5 caratteri. Mettere uno spazio nel posto sbagliato potrebbe anche fare qualcosa di completamente diverso. Altre volte, le istruzioni apparentemente ben intenzionate potevano contenere codice dannoso. Alcune persone su Internet sono molto brave a offuscare il codice.

Ci sono anche comandi che, usando html, possono essere resi della dimensione del font zero, quindi qualcosa di completamente innocuo, quando copiato negli appunti, potrebbe infatti essere l'installazione di git repo di qualcuno come una fonte attendibile e il download di malware.

E ci sono dei comandi che puoi eseguire che ti aprono per sfruttare, o che potrebbero essere perfettamente intesi, ma rimuovono file o programmi importanti o corrompono il tuo disco. In effetti, l'uso scorretto degli strumenti poteva fare qualcosa di fondamentale come scrivere accidentalmente sul tuo settore di avvio, o la testa del tuo disco, o molti altri problemi.

Un esempio di qualcosa di meno distruttivo che non è stato pubblicato sta aprendo file binari in vi . Se l'hai mai provato, saprai che può rovinare il tuo terminale fino al punto che è inutilizzabile fino a quando non è reset .

In alternativa, ci sono dei comandi che impantaneranno la tua macchina, come:

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

Puoi provare quello, non danneggerà, ma impoverirà il tuo processore e dovrai uccidere ogni processo che hai generato.

Detto questo, nel calcolo è generalmente considerato che non si può fare una frittata senza rompere qualche uovo. Dovresti essere cauto con il terminale, ma l'unico modo per migliorare l'utilizzo del sistema operativo è imparare e praticare.

Sono solo un principiante bash, ma puoi impostare un po 'True; fare COMANDO; fatto; La maggior parte delle persone proverà Ctrl + C che arresta il comando, non il processo esterno (ctrl + Z, che quindi deve essere ucciso). Immagino che se il comando è un'operazione pesante come moltiplicare un grande numero per il proprio potere, ciò potrebbe compromettere le risorse. Ma in effetti, i sistemi operativi moderni di solito sono protetti da tali problemi.

Sicuramente puoi ancora causare un arresto anomalo del sistema utilizzando i comandi immessi con Terminale.

Con gli anni sta diventando più difficile probabilmente a causa di tutti i tipi di limiti e misure protettive applicate, ma come afferma la legge di Murphy: "Nulla è infallibile per un pazzo sufficientemente capace."

"Fork bomb" e tutto ciò che è rm -rf script kiddies roba sono cose anticamente conosciute per UNIX. Con Mac OS X puoi divertirti di più usando le sue parti del sottosistema della GUI ( WindowServer per citare) o qualcosa come il firewall OpenBSD aka PF che gli ingegneri di Apple hanno introdotto ma non sono mai riusciti ad aggiornare dal suo stato del 2008. PF funziona nel kernel in modo tale che quando cattura un problema è giunto il momento Apple ti dice " tu riavviato computer a causa di un panico" o cose del genere.

La parte peggiore di questo è che non puoi mai avere un'idea di dove-n-perché è stata presa dal panico -  perché Apple non fornisce tracce di stack significative; puoi avere solo numeri esadecimali degli indirizzi di ritorno del frame dello stack.

È un po 'ambiguo cosa intendi per "crash" del tuo computer ... e non c'è una risposta definitiva definitiva, anche se ci sono alcuni esempi utili in altre risposte. Dato che la tua domanda è più ambigua e generale, vorrei concentrarmi sulla natura della domanda e dare una risposta più generale.

People who don't understand Terminal are often afraid to use it for fear that they might mess up their command and crash their computer

Penso che la linea di comando sia un'arma a doppio taglio e spesso molto affilata. Il suo più grande punto di forza è anche il suo più grande punto debole per i nuovi utenti: i programmi CLI fanno quello che dici, senza chiedere se è davvero ciò che intendevi. Spesso non chiedono conferma, non forniscono aiuto manuale o interattivo e le loro opzioni sono stringhe di testo brevi, spesso concise, a volte confuse. Notate che sono generalmente molto bene documentati, uno deve solo leggere il manuale (che è quasi sempre man <command you are about to run> ) e prendersi il tempo per capire quale sia la linea di comando stanno andando a correre lo farò.

Questa modalità di funzionamento è potente - significa che gli utenti CLI esperti possono creare "pipeline" di comandi lunghi che eseguono attività complesse con comandi singoli. Questo perché l'attività non chiederà "Sei sicuro?" in ogni fase, fa ciò che viene detto. Ma per un utente che non ha familiarità con questa modalità e utilizzato per una GUI in cui la guida in linea è un clic , non è familiare e spaventoso.

But are there actually commands that will crash your computer?

Puoi "bloccare" il tuo computer usando la CLI? Può essere. È certamente possibile causare una perdita di dati se si utilizza un comando distruttivo in modo errato. PER ESEMPIO. molte delle risposte qui menzionano rm , un comando che cancella i file. Ovviamente, puoi causare la perdita di dati con quel comando, è ciò che il comando è stato progettato per fare.

Come hanno sottolineato altre risposte, puoi usare la riga di comando per rendere la tua macchina praticamente inutilizzabile per un periodo di tempo: puoi spegnere senza conferma, perché un processo usa il 100% delle risorse disponibili senza conferma, uccide tutti i tuoi programmi o distruggi il tuo filesystem. Se lo volessi davvero, potresti usare la CLI per creare un'estensione del kernel che fa in modo che il kernel vada in panico (che è il più vicino a un "crash" a cui riesco a pensare).

La riga di comando (accessibile tramite il Terminale) è uno strumento potente. Spesso è più veloce risolvere un problema usando Terminal piuttosto che la GUI. Alcune soluzioni sono disponibili solo utilizzando i comandi Terminal. Tuttavia, la chiave per la CLI è comprensione . Non eseguire comandi casuali che vedi online. Leggi le pagine man e capisci cosa fanno i comandi. Se non sei sicuro, chiedi a qualcuno o ulteriori informazioni su un comando prima di eseguirlo.