Le persone che non capiscono Terminal hanno spesso paura di usarlo per paura di sbagliare il loro comando e mandare in crash il loro computer. Coloro che conoscono Terminal sanno che non è così, di solito Terminal genererà solo un errore. Ma ci sono effettivamente comandi che causeranno l'arresto anomalo del computer?

ATTENZIONE: potresti perdere dati se digiti questi o copi incolla, specialmente sudoe rmcomandi.

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

È possibile eseguirlo su un sistema unix:

:(){ :|: & };:

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

Non sei sicuro di cosa intendi per "arresto anomalo" del computer - se lo riformulassi per dire "rendi il computer inutilizzabile", allora sì. Certamente tutto ciò che serve è un singolo comando vagante - solo un momento in cui non stai pensando chiaramente a quello che 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, ciò può spazzare via abbastanza dal sistema per renderlo non avviabile e possibilmente causare una perdita irreversibile di dati. Non farlo

Supponiamo che tu non sappia cosa stai facendo e tentando di fare un backup di qualche disco rigido

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

Bene, se mescoli quelli (cambia if e of), sovrascriveranno i nuovi dati con quelli vecchi, senza fare domande.

Simili disguidi possono verificarsi con utilità di archivio. E francamente con la maggior parte delle utility da riga di comando.

Se vuoi un esempio di confusione di un carattere che si arresta in modo anomalo nel 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. (Sì) Bene, se si omette il punto, inizierà a spostare tutti i file. Compresi i file di sistema. Sei fortunato a non averlo fatto. Ma se leggi da qualche parte che con 'sudo -i' non dovrai mai più digitare sudo, accedi ora come root. E ora il tuo sistema si sta mangiando da solo davanti ai tuoi occhi.

Ma di nuovo penso che cose come sovrascrivere i miei preziosi file di codice con immondizia, perché ho incasinato un carattere o perché ho confuso l'ordine dei parametri, sono più problemi.

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

gcc -S program.c > program.s

Supponiamo di avere già un program.s e di utilizzare il completamento TAB. Ho fretta e dimentico di TAB due volte:

gcc -S program.c > program.c

Ora ho il codice assembler nel mio programma.c e nessun codice c più. Che è almeno una vera battuta d'arresto per alcuni, ma per altri è ricominciare da capo.

Penso che questi siano quelli che causeranno un vero "danno". Non mi interessa davvero se il mio sistema si blocca. Vorrei che i miei dati venissero persi.

Purtroppo questi sono gli errori che dovranno essere fatti fino a quando non imparerai a usare il terminale con le dovute precauzioni.

Causare un panico nel kernel è più simile allo schianto delle 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 lì effettivamente funzioni (e non ho intenzione di farlo poiché in realtà ho un po 'di lavoro aperto in questo momento).

Il macOS moderno rende davvero difficile il crash del tuo computer come utente senza privilegi (cioè senza utilizzo sudo), perché i sistemi UNIX sono pensati per gestire migliaia di utenti senza permettere a nessuno di loro di rompere l'intero sistema. Quindi, per fortuna, di solito ti verrà 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 che ti interessano che non sono protette da System Integrity Protection, i privilegi di root o le richieste di password:

Quindi, ci sono tonnellate di cose che puoi digitare che rovineranno il tuo account utente e tutti i tuoi file se non stai attento. Alcuni esempi:

• rm -rf ${TEMPDIR}/*. Questo sembra del tutto ragionevole, fino a quando non ti rendi conto che la variabile d'ambiente è scritta TMPDIR. TEMPDIRdi solito non è definito, il che rende questo rm -rf /. Anche senza sudo, questo rimuoverà felicemente tutto ciò a cui hai i permessi di cancellazione, che di solito includerà l'intera cartella home. Se lo lasci funzionare abbastanza a lungo, annuserà anche qualsiasi unità collegata al tuo computer, dato che di solito hai i permessi di scrittura per quelli.
• find ~ -name "TEMP*" -o -print | xargs rm. findindividuerà normalmente i file corrispondenti a determinati criteri e li stamperà. Senza -oquesto fa quello che ti aspetteresti ed elimina ogni file che inizia con TEMP*( purché non ci siano spazi nel percorso ). Ma -osignifica "o" (non "output" come per molti altri comandi!), Facendo sì che questo comando elimini effettivamente tutti i tuoi file. Bummer.
• ln -sf link_name /some/important/file. La sintassi di questo comando viene errata di tanto in tanto, e sovrascrive piuttosto felicemente il tuo file importante con un inutile collegamento simbolico.
• kill -9 -1 ucciderà tutti i tuoi programmi, disconnettendoti piuttosto rapidamente e probabilmente causando la perdita di dati.

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

sudo chmod 0 /

Ciò renderà inaccessibile l'intero file system (che significa tutti i comandi e i programmi) ... tranne l'utente root. Ciò significa che dovresti accedere direttamente come utente root e ripristinare il file system, MA non puoi accedere al sudocomando (o qualsiasi altro comando, per quella materia). È possibile ripristinare l'accesso a comandi e file avviando in modalità utente singolo, montando e ripristinando il file system chmod 755 /.

Se questo viene fatto in modo ricorsivo, chmod -R 0 /ciò renderà il sistema inutilizzabile. La correzione corretta a quel punto è quella di utilizzare Utility Disco dalla partizione di ripristino per riparare le autorizzazioni del disco . Potrebbe essere meglio solo ripristinare un'istantanea o un backup del file system se questo è stato eseguito in modo ricorsivo.

Le risposte che chiamano sudodevono essere considerate non valide. Questi presuppongono già l'accesso amministrativo al sistema.

Prova perl -e 'exit if fork;for(;;){fork;}'. OSX potrebbe avere qualche protezione contro questo ora. Se è presente una bolla di apple che ti chiede se vuoi terminare l'app Terminale e i sottoprocessi, 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 & donefarà solo un piccolo test di carico della CPU divertente. Ottimo per verificare se il dissipatore di calore e la ventola sono all'altezza.

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

Supponendo quindi sudodi essere root, il Mac si arresta in modo anomalo.

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

Perdi quelle protezioni ed è per questo che avverto le persone che iniziano con l'app terminale o SSH. Se hai un backup che sai che funziona e hai il tempo e la fiducia / abilità per eseguire un ripristino, allora dovresti immergerti e imparare e persino rompere le cose.

sudo kill -9 -1  

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

Non ho mai provato quel sudo kill -9 -1comando dalla riga di comando. Potrebbe non funzionare, perché l'ID processo "-1" significa "uccidi 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 -1sicuramente fermerai immediatamente - proprio come tirare il cavo di alimentazione. A proposito: nei file di registro non apparirà nulla, perché quel comando è il killer più veloce dell'ovest!

In realtà, per riprendermi, sono andato dai nostri amministratori di sistema e ho detto loro cosa facevo. Hanno eseguito un riavvio forzato, poiché non era possibile accedere a quel server (RHEL6).

A kill -9 -1come root uccide ogni processo, che viene eseguito come root. Cioè sshd. Ciò mi ha disconnesso immediatamente e ha impedito a chiunque di accedere nuovamente. Qualsiasi processo avviato da init, incluso init, è stato interrotto, a meno che non abbiano modificato UID o GID. Anche l'accesso tramite la console seriale non era più possibile. ps -eaf | grep rootmostra alcuni processi fantasiosi, che, se reagiscono su un SIGKILL nel modo predefinito, fermerebbero praticamente anche la scrittura di base su HD.

Non ci proverò ora sul mio laptop :-) Non sono abbastanza curioso di scoprire se un kill -9 165([ext4-rsv-convert]) smetterebbe davvero di scrivere su HD.

Sì, puoi distruggere completamente il tuo sistema. Fare accidentalmente qualcosa con sudoprivilegi è un esempio che è stato pubblicato, sia che si dimentichi qualche personaggio che indica al terminale di fare qualcosa di completamente diverso da quello che si intendeva. rming /invece di /tmp/\*è solo una differenza di 5 caratteri. Mettere uno spazio nel posto sbagliato potrebbe fare anche qualcosa di completamente diverso. Altre volte, istruzioni apparentemente ben intenzionate potrebbero avere il codice maligno offuscato in esso. Alcune persone su Internet sono molto brave a offuscare il codice.

Ci sono anche comandi che, usando html, possono rendere la dimensione del carattere pari a zero, quindi qualcosa di completamente innocuo dall'aspetto, quando viene copiato negli appunti, potrebbe effettivamente installare il repository git di qualcuno come fonte attendibile e scaricare malware.

E ci sono comandi che puoi eseguire che ti aprono a sfruttare, o che potrebbero essere perfettamente ben intenzionati ma rimuovono file o programmi importanti o corrompono il tuo disco. In effetti, l'uso errato degli strumenti potrebbe fare qualcosa di semplice come la scrittura accidentale sul settore di avvio, sul capo del disco o su molti altri problemi.

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

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

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

Puoi provarlo, non danneggerà, ma bloccherà il tuo processore e dovrai uccidere ogni processo che hai generato.

Detto questo, nel calcolo è generalmente considerato che non puoi fare una frittata senza rompere alcune uova. Dovresti essere cauto al terminale, ma l'unico modo per migliorare l'utilizzo del sistema operativo è l'apprendimento e la pratica.

Sono solo un principiante bash, ma potresti impostare un po 'True; fare COMANDO; fatto; La maggior parte delle persone proverebbe Ctrl + C che interromperà 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 rovinare le risorse. Ma in effetti, i moderni sistemi operativi di solito sono protetti da tale confusione.

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

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

Le "bombe a forcella" e tutte le rm -rfcose dei kiddies degli script sono cose anticamente conosciute per UNIX. Con Mac OS X puoi divertirti di più usando le sue parti del sottosistema della GUI ( WindowServerper citare) o qualcosa come il firewall OpenBSD noto anche PFcome gli ingegneri di Apple, ma che non sono mai riusciti ad aggiornare dal suo stato delle cose del 2008. PFfunziona nel kernel, quindi quando rileva una stranezza è ora che Apple ti dica " hai riavviato il computer a causa di un panico" o cose del genere.

La parte peggiore di questo è che non puoi mai avere idea di dove-n-perché sia ​​andato nel panico, perché Apple non fornisce alcuna traccia di stack significativa; puoi avere solo numeri esadecimali di indirizzi di ritorno del frame dello stack.

È un po 'ambiguo ciò che intendi per "crash" del tuo computer ... e non esiste una risposta corretta definitiva, anche se ci sono alcuni esempi utili in altre risposte. Poiché la tua domanda è più ambigua e generale, mi piacerebbe concentrarmi sulla natura della domanda e dare una risposta più generale.

Le persone che non capiscono Terminal hanno spesso paura di usarlo per paura di sbagliare il loro comando e mandare in crash il loro computer

Penso che la linea di comando sia un'arma a doppio taglio, e spesso molto affilata. La sua più grande forza è anche la sua più grande debolezza per i nuovi utenti: i programmi CLI fanno quello che dici, senza chiedere se è davvero quello che volevi dire. Spesso non chiedono conferma, non forniscono aiuto manuale o interattivo e le loro opzioni sono stringhe di testo brevi, spesso concise, a volte confuse. Si noti che sono generalmente molto ben documentati, basta leggere il manuale (che è quasi sempre man <command you are about to run>) e prendere il tempo per capire quale sarà la linea di comando che eseguiranno.

Questa modalità operativa è potente - significa che gli utenti CLI esperti possono creare lunghe "pipeline" di comandi che eseguono compiti complessi con singoli comandi. Questo perché l'attività non chiederà "Sei sicuro?" ad ogni passo, fa quello che gli viene detto. Ma per un utente che non ha familiarità con questa modalità e utilizzato per una GUI in cui la guida in linea è a portata di clic , non è familiare e spaventosa.

Ma ci sono effettivamente comandi che causeranno l'arresto anomalo del computer?

Puoi "bloccare" il tuo computer usando la CLI? Può essere. Puoi certamente causare la perdita di dati se usi un comando distruttivo in modo errato. Ad esempio, molte delle risposte qui menzionate rm, un comando che elimina i file. Ovviamente, è possibile causare la perdita di dati con quel comando, è ciò che il comando è stato progettato per fare.

Come hanno indicato altre risposte, è possibile utilizzare la riga di comando per rendere la macchina praticamente inutilizzabile per un periodo di tempo: è possibile arrestare senza conferma, fare in modo che un processo utilizzi il 100% delle risorse disponibili senza conferma, uccidere tutti i programmi o distruggi il tuo filesystem. Se lo si desidera, è possibile utilizzare l'interfaccia della riga di comando per creare un'estensione del kernel che provoca il panico del kernel (che è il più vicino a un "crash" che mi viene in mente).

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