Pouvez-vous réellement utiliser Terminal pour planter votre ordinateur?

48

Les personnes qui ne comprennent pas Terminal ont souvent peur de l’utiliser, de peur de gâcher leur commande et de mettre leur ordinateur en panne. Ceux qui connaissent Terminal savent mieux que ce n'est pas le cas - généralement, Terminal émettra simplement une erreur. Mais y a-t-il réellement des commandes qui planteront votre ordinateur?

AVERTISSEMENT: vous risquez de perdre des données si vous tapez ces ou copier - coller, en particulier sudoet les rmcommandes.

DonielF
la source
Un gars a accidentellement effacé tous les ordinateurs de son entreprise en une seule ligne. Je l'ai vu sur ce site il y a quelques années. C'était faux, mais cela pouvait toujours se produire. Je créerai un lien si je peux le trouver.
Noah Cristino
7
Le terminal n'est qu'une interface de ligne de commande pour l'exécution de programmes. C'est une alternative à une interface utilisateur graphique . Vous pouvez exécuter des programmes arbitraires de l'un ou l'autre. Votre question n’a donc pas beaucoup de sens; vous devriez plutôt demander: pouvez-vous mettre votre ordinateur en panne en exécutant un programme?
jamesdlin
Qu'entendez-vous par "crash"? Les commandes exécutées dans le terminal peuvent souvent être puissantes et vont souvent "faire ce que vous dites et non ce que vous voulez dire" sans demander, contrairement à la plupart des commandes de l'interface graphique de Mac OS X. Mais à moins que vous n'essayiez intentionnellement de le faire , il est peu probable que vous plantiez la machine. (Je peux penser à quelques façons de le faire intentionnellement cependant)
Josh
1
Le collage de commandes sur le Web peut être très dangereux . Indépendamment de la possibilité d'accrocher votre machine. Taper des commandes que vous comprenez au moins vaguement ne devrait cependant pas être dangereux. Sinon beaucoup de façons de visser votre ordinateur. C'est comme cliquer sur des paramètres de configuration système aléatoires dans l'interface graphique, mais au moins dans l'interface graphique, les possibilités sont plus limitées. Risque de coller des commandes - le texte que vous voyez visuellement copié peut être différent du texte copié. Il peut donc contenir des commandes malveillantes mélangées.
akostadinov
@ иσαнcяişтiпσ Peut-être serverfault.com/questions/769357/recovering-from-a-rm-rf
wythagoras

Réponses:

51

Une façon de planter un ordinateur consiste à exécuter une soi-disant bombe à la fourche .

Vous pouvez l'exécuter sur un système Unix en:

:(){ :|: & };:

C'est une commande qui va générer des processus de manière récursive jusqu'à ce que le système d'exploitation soit si occupé qu'il ne répondra plus à aucune action.

Rick van Hal
la source
49
@ bunyaCloven si je comprends bien votre commande, il s’agit d’une commande qui permet de supprimer tous les dossiers sans le demander , ce qui est très dangereux si cela fonctionne . Je souhaite que vous avez écrit un avertissement pour cela.
Andrew T.
80
@AndrewT. Les gens ne devraient pas taper bon gré mal gré des commandes qu'ils ont trouvées sur Internet. (surtout ceux dans un fil de discussion appelé "pouvez-vous planter votre ordinateur via un terminal")
John Hamilton
34
Le PO a demandé un accident au terminal, pas une lingette.
Piersb
16
La bombe à la fourche causera en réalité des dégâts minimaux sur Mac OS X car elle a une limite supérieure pour le nombre de processus.
GDP2
7
@bunyaCloven remplace le ;avec un &et vous pourrez supprimer tous les fichiers et bombarder la bombe en même temps, et voir ce qui casse le système en premier!
Muzer
41

Vous ne savez pas vraiment ce que vous entendez par "plantage" de l'ordinateur - si vous reformuliez le libellé pour dire "rendre l'ordinateur inutilisable", alors oui. Il ne fait aucun doute qu’il ne faut qu’une simple commande parasite - un moment où vous ne réfléchissez pas clairement à ce que vous faites, comme lorsque vous parlez sans réfléchir, et que les dégâts peuvent être immenses et presque immédiats. L'exemple classique:

$ sudo rm -rf /

Si vous laissez cette commande s'exécuter pendant une seconde à peine, cela peut effacer suffisamment de votre système pour la rendre non amorçable et éventuellement provoquer une perte de données irréversible. Ne le fais pas.

Harv
la source
2
Et juste pour expliquer pourquoi je voulais clarifier la reformulation… pour «planter» l'ordinateur au sens traditionnel - pour le verrouiller - vous auriez besoin de laisser à la CPU suffisamment de travail pour qu'elle ne puisse pas répondre de manière opportune pour d’autres tâches, comme la mise à jour des graphiques et le déplacement du curseur, par exemple. Je suis sûr qu'il existe un moyen de faire cela à partir de la ligne de commande.
Harv
6
@DonielF -rsignifie supprimer récursivement des fichiers dans un répertoire. -fsignifie "forcer" car ne demandez pas de confirmation, quelles que soient les autorisations d'un fichier. /est le répertoire racine du système de fichiers, ce qui signifie qu'il va tout détruire, à l'exception peut-être de certains fichiers spéciaux qui ne se comportent pas comme des fichiers classiques. En outre, vous aurez du mal à trouver une brève commande qui plantera votre système sans autorisations root / admin.
GDP2
11
J'ai essayé il y a rm -rf /un certain temps et j'ai rmdit que si vous voulez supprimer la racine, utilisez tel drapeau. Aucune donnée n'a été perdue. Il semble qu’il existe actuellement une protection de sécurité contre les exécutions aveugles rm -rf /.
alexyorke
27
--no-preserve-root est nécessaire depuis 2006 pour que tout fonctionne
correctement
6
Voici un cas rm -rf
concret
30

Supposons que vous ne sachiez pas ce que vous faites et tentez de sauvegarder un disque dur

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

Eh bien, si vous les mélangez (changez si et de), cela écrasera les nouvelles données avec les anciennes données, sans poser de questions.

Des mélanges similaires peuvent se produire avec des utilitaires d'archives. Et franchement avec la plupart des utilitaires de ligne de commande.

Si vous souhaitez un exemple de confusion d'un caractère susceptible de bloquer votre système, examinez le scénario suivant: vous souhaitez déplacer tous les fichiers du répertoire actuel vers un autre:

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

Acceptons le fait que vous avez appris à utiliser ./pour désigner le répertoire actuel. (Oui) Si vous omettez le point, tous vos fichiers seront déplacés . Y compris vos fichiers système. Vous avez de la chance de ne pas avoir vu ça. Mais si vous lisez quelque part que, avec 'sudo -i', vous ne devrez plus jamais taper sudo, vous êtes maintenant connecté en tant que root. Et maintenant, votre système se mange devant vos yeux.

Mais encore une fois, je pense que des choses comme écraser mes précieux fichiers de code avec des ordures, parce que j'ai foiré un caractère ou parce que j'ai mélangé l'ordre des paramètres, est plus un problème.

Supposons que je veuille vérifier le code assembleur généré par gcc:

gcc -S program.c > program.s

Supposons que j'ai déjà eu un programme et que j'utilise la complétion par tabulation. Je suis pressé et j'oublie de taper deux fois:

gcc -S program.c > program.c

Maintenant, j'ai le code assembleur dans mon programme.c et plus de code c. Ce qui est au moins un réel revers pour certains, mais pour d’autres, c’est le temps de repartir à zéro.

Je pense que ce sont ceux qui vont causer un véritable "préjudice". Je ne me soucie pas vraiment si mon système tombe en panne. Je voudrais que mes données soient perdues.

Malheureusement, ce sont les erreurs qui devront être faites jusqu'à ce que vous appreniez à utiliser le terminal avec les précautions appropriées.

Mr Paulch
la source
16
Votre dernier point est l'une des nombreuses raisons pour lesquelles tout le monde devrait utiliser le contrôle de version
Darren H
4
Une fois, j'ai détruit un programme sur lequel je travaillais, gcc program.c -o program.cgrâce précisément à la complétion par onglets. J'ai appris à utiliser religieusement le contrôle de version par la suite.
nneonneo
2
La meilleure solution à ce jour est d’afficher des commandes légitimes qui pourraient résulter d’une simple faute de frappe et qui pourraient entraîner des dommages importants.
Gaazkam
1
"Maintenant, j'ai le code assembleur dans mon programme.c" Nope. Tu n'as rien. La redirection a tronqué le fichier avant même que GCC ne l'ouvre.
muru
1
Oh mec, je suis vraiment heureux qu'ils aient ajouté cette amélioration de l'interface utilisateur dans GCC. Cela fait un moment depuis ma dernière gaffe, mais il est agréable de voir que je serai un peu protégé de cette prochaine fois.
nneonneo
28

Céder à la panique du noyau revient plus à planter que les autres réponses que j'ai vues jusqu'ici:

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

(code extrait d' ici et figurant également dans la propre documentation d'Apple )

Vous pourriez aussi essayer:

sudo killall kernel_task

Je n'ai pas vérifié que le deuxième poste fonctionnait réellement (et je n'ai pas l'intention de le faire, car certains travaux sont actuellement ouverts).

GDP2
la source
2
Je viens d'essayer le second d'une VM 10.12.3, et on dit juste:No matching processes were found
Alexander O'Mara le
3
En outre, le premier ne semble pas fonctionner, du moins si le protocole SIP est activé,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 le
@ AlexanderO'Mara Pas très surpris de vos résultats sur la deuxième commande; Je pensais que Mac OS X ne vous autoriserait pas à arrêter le processus du noyau de cette manière. Les résultats de la première commande sont également à prévoir, comme cela a dtraceété effectivement neutralisé par SIP.
GDP2
1
kernel_taskn'est pas un processus normal. C'est immortel; Il ne peut être tué que par une erreur qui lui est propre (et qui s'appellerait un KP et abat la machine entière). kernel_taskLe PID de est nominalement 0, mais si vous le fournissez au kill(pid, sig)syscall, la page de manuel indique Si pidest égal à 0, il sigest envoyé à chaque processus du groupe de processus du processus appelant. . Vous ne pouvez donc tout simplement pas envoyer de kernel_tasksignal.
Iwillnotexist Idonotexist
@IwillnotexistIdonotexist Ouais, je pensais que ce serait le cas; Merci néanmoins pour l'info. Bonnes choses à avoir à l'esprit.
GDP2
19

MacOS moderne rend très difficile le blocage de votre machine en tant qu'utilisateur non privilégié (c'est-à-dire sans utiliser sudo), car les systèmes UNIX sont conçus pour gérer des milliers d'utilisateurs sans laisser aucun d'entre eux détruire le système entier. Donc, heureusement, vous devrez généralement être invité avant de faire quelque chose qui détruit votre machine.

Malheureusement, cette protection ne concerne que le système lui-même. Comme le montre xkcd, vous vous souciez de nombreuses choses qui ne sont pas protégées par la protection de l'intégrité du système, les privilèges root ou les invites de mot de passe:

XKCD 1200

Donc, il y a des tonnes de choses que vous pouvez taper qui vont juste détruire votre compte utilisateur et tous vos fichiers si vous ne faites pas attention. Quelques exemples:

  • rm -rf ${TEMPDIR}/*. Cela semble tout à fait raisonnable, jusqu'à ce que vous réalisiez que la variable d'environnement est orthographiée TMPDIR. TEMPDIRest généralement indéfini, ce qui rend cela rm -rf /. Même sans sudocela, cela supprimera avec plaisir tout ce que vous avez l'autorisation de supprimer, ce qui inclut généralement tout votre dossier personnel. Si vous le laissez fonctionner assez longtemps, il supprimera également tout lecteur connecté à votre ordinateur, puisque vous y avez généralement des droits en écriture.
  • find ~ -name "TEMP*" -o -print | xargs rm. findcherchera normalement les fichiers correspondant à certains critères et les imprimera. Sans le, -ocela fait ce que vous attendez et supprime tous les fichiers commençant par TEMP*( tant que vous n'avez pas d'espaces dans le chemin ). Mais, les -omoyens "ou" (pas "sortie" comme c'est le cas pour beaucoup d'autres commandes!), Faisant que cette commande supprime réellement tous vos fichiers. Bummer.
  • ln -sf link_name /some/important/file. La syntaxe de cette commande est parfois erronée, et il remplacera plutôt votre fichier important par un lien symbolique inutile.
  • kill -9 -1 va tuer chacun de vos programmes, vous déconnecter assez rapidement et éventuellement causer des pertes de données.
Nneonneo
la source
3
FYI (pour les autres lisant ceci) finda un -deleteargument qui est beaucoup plus sûr que la tuyauterie versxargs rm
Josh
Le MacOS moderne est-il vraiment plus résistant aux chocs? La plupart de ces systèmes sont destinés à un seul utilisateur. Ont-ils vraiment maxprocs / cpulimits sains? Pouvez-vous fournir une référence?
user2497
1
Tout le monde sait très bien que le mal ln -sfpeut faire ... et comment s'en remettre :-)
Iwillnotexist Idonotexist
1
@ Josh: merci de l'avoir signalé. Et, dans le cas général, il faut utiliser find -print0 | xargs -0pour gérer en toute sécurité des caractères étranges dans les noms de fichiers.
Nneonneo
1
D'accord. Conseil xargs plus utile: utilisez d’ <whatever> | xargs echo <something>abord pour prévisualiser les commandes réellement exécutées par xargs. xargs est un excellent exemple de la puissance de la CLI: vous pouvez manipuler de nombreux objets à la fois sans confirmation ni manipulation fastidieuse ... assurez-vous simplement de lui dire de faire ce que vous voulez.
Josh
16

Un autre que vous pouvez faire (que j'ai fait par erreur auparavant) est:

sudo chmod 0 /

Cela rendra votre système de fichiers entier (ce qui signifie toutes les commandes et tous les programmes) inaccessible ... sauf par l'utilisateur root. Cela signifie que vous devez vous connecter directement en tant qu'utilisateur root et restaurer le système de fichiers, MAIS vous ne pouvez pas accéder à la sudocommande (ni à aucune autre commande, d'ailleurs). Vous pouvez restaurer l'accès aux commandes et aux fichiers en démarrant en mode mono-utilisateur, en montant et en restaurant le système de fichiers avec chmod 755 /.

Si cela est fait de manière récursive avec chmod -R 0 /alors cela rendra le système inutilisable. Le correctif approprié à ce stade consiste à utiliser Utilitaire de disque à partir de la partition de récupération pour réparer les autorisations du disque . Vous aurez peut-être intérêt à simplement restaurer un instantané ou une sauvegarde de votre système de fichiers si cela a été exécuté de manière récursive.

musicman523
la source
8
"Vous pouvez résoudre le problème en ... chmod 755 /" - Non, vous ne pouvez pas. De nombreux fichiers nécessitent des autorisations différentes de 755, soit pour des raisons de sécurité, soit pour fonctionner du tout. chmod 755 /laissera votre système instable et cassé de manière subtile. La seule récupération complète à partir de chmod 0 /consiste en une restauration par image instantanée, une restauration en sauvegarde et / ou une réinstallation.
marcelm
2
@marcelm Bon point. Ma suggestion était seulement de restaurer l'accès aux commandes, pas comme une solution permanente. J'ai mis à jour ma réponse pour refléter cela. Autant que je sache, chmod n'est pas récursif à moins que vous n'utilisiez le -Rdrapeau. Je pensais donc que les autorisations des sous-répertoires ne seraient pas affectées.
musicman523
5
@marcelm vous avez raison, mais la commande affichée n'est pas récursive, donc seule /est affectée.
Andrea Lazzarotto
J'ai déjà eu sudo chmod -R 700 /un nouvel ordinateur, pensant qu'il serait beaucoup plus sûr si je le faisais. Étonnamment, il a démarré et s'est retrouvé avec une barre de menu vide et un bureau vierge. Rien d'autre n'a fonctionné, mais les autorisations de restauration de l'utilitaire de disque de la partition de récupération ont en réalité réussi à régler presque tout!
nneonneo
2
L'utilitaire de disque @marcelm a une option "Réparer les autorisations" qui devrait corriger cela sans restauration complète du système
Josh
10

Les réponses à cet appel sudodoivent être considérées comme non valides. Ceux-ci supposent déjà un accès administratif au système.

Essayez perl -e 'exit if fork;for(;;){fork;}'. OSX peut avoir une certaine protection contre cela maintenant. Si vous présentez une bulle de pomme vous demandant si vous souhaitez mettre fin à l'application Terminal et aux sous-processus, vous êtes (presque) bien.

while true ; do cat /dev/zero > /dev/null & doneest également très pratique, esp. si vous n'avez pas perl.

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & donefera juste un petit test de charge du processeur drôle. Très bon pour vérifier si votre radiateur et votre ventilateur sont à la hauteur.

utilisateur2497
la source
Ceci est connu sous le nom de Fork Bomb et rendra probablement le système inutilisable (pourrait être considéré comme un "crash"), mais ne causera probablement aucun dommage permanent. Mais c'est méchant!
Josh
@Josh "mais ne causera probablement aucun dommage permanent" À l'exception de tout travail non enregistré actuellement ouvert.
Reirab
@reirab Josh a ajouté la fourchette «probable» à sa déclaration. Mais MacOS est principalement destiné à l'édition de photos et de vidéos. Les programmes Adobe ne disposent-ils pas de sauvegarde automatique automatique?
user2497
1
En outre, le travail non enregistré est toujours en danger jusqu'à ce qu'il soit enregistré. Si votre ordinateur est rendu inutilisable, vous ne pouvez pas sauvegarder ce que vous avez ouvert :)
Josh
@Josh MacOS est si facile de sauvegarder des fichiers. C'est toujours du-S. Vous n'auriez pas dû écrire 'probable'
user2497
7

Bien sûr, assurez-vous d'avoir une sauvegarde et enregistrez tous les fichiers qui vous intéressent, puis tapez halt

En supposant que vous utilisiez alors le statut sudoroot, le Mac plantera.

Le plus gros risque de la ligne de commande est la perte de données. L’interface macOS est conçue sur plusieurs décennies pour ne pas surprendre les gens et détruire leurs données, paramètres ou applications. L’interface graphique macOS existe également pour supprimer la courbe d’apprentissage (une courbe raide) permettant d’être sûr et de maîtriser les scripts shell.

Vous perdez ces protections, raison pour laquelle je mets en garde les personnes commençant par terminal app ou ssh. Si vous avez une copie de sauvegarde qui fonctionne et que vous avez le temps, la confiance et les compétences nécessaires pour effectuer une restauration, vous devez vous y plonger, apprendre et même casser des choses.

bmike
la source
3
Vous avez dit "... et même casser des choses", ce qui est un bon cas d'utilisation pour faire des tâches risquées dans une machine virtuelle. :)
utilisateur3439894
1
Comment va ce crash? Cela ferme simplement le système immédiatement. Il élimine même les tampons du noyau afin d'éviter toute perte de données (enregistrée). developer.apple.com/legacy/library/documentation/Darwin/…
Josh
7
sudo kill -9 -1  

J'ai accidentellement effectué un kill -9 -1script dans un script Perl, en cours d'exécution en tant que root. C'était aussi rapide que de tirer le cordon d'alimentation. Au redémarrage, le serveur a effectué une vérification du système de fichiers et a continué à fonctionner correctement.

Je n'ai jamais essayé cette sudo kill -9 -1commande sur la ligne de commande. Cela pourrait ne pas fonctionner car l'ID de processus "-1" signifie "tuer tous les processus appartenant au groupe de processus de l'appelant".

Pas sûr, si avec sudo, cela signifie aussi init et tout ce qui concerne le noyau ... Mais si vous êtes root, vous kill -9 -1ferez un arrêt immédiat - comme si vous tiriez sur le cordon d'alimentation. Au fait, rien n’apparaîtra dans les fichiers journaux, car cette commande est le tueur le plus rapide de l’Ouest!

En fait, pour récupérer, je suis allé voir nos administrateurs système et leur ai dit ce que je faisais. Ils ont procédé à un redémarrage difficile car il n'y avait aucun moyen de se connecter sur ce serveur (RHEL6).

Une kill -9 -1racine en tant que racine tue tous les processus exécutés en tant que racine. C'est-à-dire sshd. Cela m'a immédiatement déconnecté et a empêché quiconque de se connecter à nouveau. Tous les processus lancés par init, y compris init, ont été supprimés, sauf s'ils ont changé d'UID ou de GID. Même se connecter via une console série n’était plus possible. ps -eaf | grep rootmontre quelques processus fantaisistes qui, s’ils réagissaient sur un SIGKILL de manière standard, arrêteraient pratiquement l’écriture, même élémentaire, sur HD.

Je ne vais pas essayer cela maintenant sur mon ordinateur portable :-) Je ne suis pas assez curieux pour savoir si un kill -9 165([ext4-rsv-conver]) arrêterait vraiment d'écrire sur la HD.

bubi6608
la source
Vous ne pouvez pas "tuer" le noyau, et cela ne devrait pas provoquer une vérification du système de fichiers en soi. Comment avez-vous récupéré de la situation? Avez-vous fait un redémarrage difficile? Parce que c'est probablement ce qui a causé la vérification du système de fichiers :)
Josh
Votre réponse modifiée a du sens. En réalité init, vous ne pouvez pas tuer normalement, mais vous pouvez tuer tous les gettys et les sessions SSH et rendre la machine inutilisable. Un Magic SysRq aurait dû permettre un redémarrage propre, mais il est souvent plus facile de simplement redémarrer et de s'appuyer sur le journal FS :)
Josh
5

Oui, vous pouvez complètement détruire votre système. Par exemple, faire accidentellement quelque chose avec des sudoprivilèges est un exemple publié, qu'il s'agisse d'oublier quelques caractères qui demandent au terminal de faire quelque chose de complètement différent de ce que vous aviez prévu. rming au /lieu de /tmp/\*seulement une différence de 5 caractères. Mettre un espace au mauvais endroit peut aussi faire quelque chose de complètement différent. D'autres fois, des instructions apparemment bien intentionnées pourraient avoir un code malveillant dissimulé dans celui-ci. Certaines personnes sur Internet sont très douées pour obscurcir le code.

Il existe également des commandes qui, à l’aide du langage HTML, permettent de définir une taille de police égale à zéro. Une copie complètement inoffensive, lorsqu’elle est copiée dans le Presse-papiers, pourrait en fait être l’installation du dépôt git de quelqu'un en tant que source de confiance et le téléchargement de programmes malveillants.

Et il y a des commandes que vous pouvez exécuter qui vous ouvrent à exploiter, ou qui pourraient être parfaitement bien intentionnées mais suppriment des fichiers ou des programmes importants ou corrompt votre disque. En fait, utiliser des outils de manière incorrecte pourrait faire quelque chose d'aussi fondamental que d'écrire accidentellement sur votre secteur de démarrage, sur la tête de votre disque ou sur de nombreux autres problèmes.

Un exemple de quelque chose de moins destructeur qui n’a pas été posté est l’ouverture de fichiers binaires dans vi. Si vous l'avez déjà essayé, vous saurez qu'il peut gâcher votre terminal au point de le rendre inutilisable jusqu'à ce qu'il le soit reset.

Alternativement, il y a des commandes qui enlèveront votre machine, comme:

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

Vous pouvez essayer celui-là, cela ne fera pas de dégâts, mais votre processeur s'enlisera, et vous devrez tuer chaque processus que vous avez créé.

Cela étant dit, en informatique, il est généralement admis que vous ne pouvez pas créer une omelette sans casser quelques œufs. Vous devez être prudent au niveau du terminal, mais la seule façon d’améliorer l’utilisation du système d’exploitation réside dans l’apprentissage et la pratique.

JFA
la source
Votre premier exemple est à peine nuisible. Vim est en fait assez sain d'esprit lors de l'édition de fichiers binaires. Et dans le pire des cas, vous pouvez simplement fermer la fenêtre. Le deuxième exemple avec "oui" est ennuyeux et utilisera une bonne partie de la CPU de l'utilisateur, mais le système restera réactif et vous pourrez facilement tuer la fenêtre du terminal parent.
nneonneo
1
Je ne suis pas d'accord avec "gâchez votre terminal au point qu'il soit inutilisable jusqu'à ce que vous le redémarriez" - essayez reset, cela devrait effacer un terminal sur lequel une sortie binaire a été imprimée. ou, juste créer un nouvel ATS
Josh
1
Cool, nw @ JFA. En fait, il m'a fallu plusieurs années pour apprendre le resettruc! Pour plus d'informations: unix.stackexchange.com/questions/79684
Josh
1
@Josh merci pour cela, c'était une grande aide. Cela fait en effet de nombreuses années pour moi: P
JFA
1
@Josh Ensuite, 'stty sane ^ m' et 'tput reset' devraient également vous intéresser.
user2497
4

Je ne suis qu'un débutant, mais vous pouvez définir un moment vrai; faire le commandement; terminé; La plupart des gens essaieraient Ctrl + C qui arrêterait la commande, pas le processus externe (Ctrl + Z, qui doit ensuite être tué). Je suppose que si la commande est une opération lourde, telle que multiplier un grand nombre à leur propre puissance, cela pourrait gâcher vos ressources. Mais en effet, les systèmes d’exploitation modernes sont généralement protégés contre de tels dégâts.

Ando Jurai
la source
2
Il court très vite, il ne plante rien. Vous devez juste effectuer des calculs intensifs pour que le noyau maxprocs ne vous rende pas triste. essayerwhile true do cat /dev/zero > /dev/null & done
user2497
Merci. Je me serais attendu à ce que la gestion de grands nombres ralentisse le fonctionnement de l'ordinateur. Cela arrivait parfois avec de très simples programmes java / python que j'utilisais pour l'apprentissage automatique.
Ando Jurai
1
Le bit de cat. Zéro à zéro est une opération à grand nombre, du moins en entrée / sortie. J'utilise l'un de ceux-ci par cœur de processeur pour effectuer des tests thermiques.
user2497
1
Et ^C va tuer la boucle while aussi, mais il répète tout simplement trop rapide pour l'interruption d'être pris. Le maintien ^Cpeut sortir de la boucle. La fermeture du terminal sera également :)
Josh
2
@Josh Il est plus facile de capturer l'INT s'il y a une petite pause, telle que dormir 0.1, après la tâche intensive en cpu.
user2497
3

Vous pouvez toujours provoquer un crash du système en utilisant les commandes entrées avec Terminal.

Avec les années, cela devient de plus en plus difficile probablement à cause de toutes sortes de limites et de mesures de protection appliquées, mais comme le dit la loi semblable à celle de Murphy: "Rien n'est infaillible pour un imbécile suffisamment capable."

Les "bombes à la fourchette" et tous ces rm -rfscripts pour enfants sont des choses connues autrefois pour UNIX. Avec Mac OS X, vous pouvez avoir plus de plaisir en utilisant ses composants de sous-système graphique ( WindowServerà mentionner) ou quelque chose comme le pare-feu OpenBSD, autrement dit PFque les ingénieurs d’Apple ont importé mais n’ont jamais réussi à mettre à jour depuis son état de 2008. PFfonctionne dans le noyau, donc quand il détecte un caprice, il est temps qu'Apple vous dise " vous avez redémarré l'ordinateur en raison d'une panique" ou quelque chose comme ça.

Le pire, c’est que vous ne pouvez jamais avoir une idée de la raison pour laquelle il a paniqué, car Apple ne fournit aucune trace de pile significative; vous ne pouvez avoir que des nombres hexadécimaux d'adresses de retour du cadre de pile.

poige
la source
Bonne réponse et excellents points. Je souhaiterais ajouter à votre liste de solutions permettant à OS X de s'affoler sur la piste de danse comme mon préféré, mais sans termes explicites afin d'éviter les sottises du scénario. Je décharge une extension de noyau pertinente pour NFC. Fonctionne à chaque fois, instantanément. On peut facilement transformer cela en DOS en le programmant à un nombre divisible de 5 minutes. Par conséquent, il va démarrer puis plonger Cygne. Cela nécessite une réinstallation du système d'exploitation étant donné la plupart des administrateurs et même les techniciens vont manquer cela ....
Francis de ResponseBase le
3

Ce que vous entendez par "planter" votre ordinateur est un peu ambigu ... et il n'y a pas de réponse correcte définitive à cela, bien qu'il y ait des exemples utiles dans d'autres réponses. Étant donné que votre question est plus ambiguë et plus générale, je voudrais aborder la nature de la question et donner une réponse plus générale.

Les personnes qui ne comprennent pas Terminal ont souvent peur de l'utiliser, de peur de gâcher leur commande et de mettre leur ordinateur en panne.

Je pense que la ligne de commande est une épée à double tranchant et souvent très tranchante. Sa plus grande force est également sa plus grande faiblesse pour les nouveaux utilisateurs: les programmes CLI font ce que vous dites, sans vous demander si c'est vraiment ce que vous voulez dire. Souvent, ils ne demandent pas de confirmation, ils ne fournissent pas d'aide manuelle ou interactive, et leurs options sont courtes, souvent laconiques, parfois source de confusion. Notez qu'ils sont généralement très bien documentés, il suffit de lire le manuel (qui est presque toujours man <command you are about to run>) et de prendre le temps de comprendre ce que la ligne de commande qu'ils vont exécuter va faire.

Ce mode de fonctionnement est puissant : cela signifie que les utilisateurs chevronnés de la CLI peuvent créer des "pipelines" de commandes longues qui effectuent des tâches complexes avec des commandes simples. C'est parce que la tâche ne demandera pas "Êtes-vous sûr?" à chaque étape, il fait ce qui est dit. Mais pour un utilisateur peu familiarisé avec ce mode et habitué à une interface graphique où l’aide en ligne est accessible en un clic , il est inconnu et effrayant.

Mais y a-t-il réellement des commandes qui planteront votre ordinateur?

Pouvez-vous "planter" votre ordinateur en utilisant la CLI? Peut être. Vous pouvez certainement causer une perte de données si vous utilisez une commande destructive de manière incorrecte. Par exemple, bon nombre des réponses mentionnées ici sont rmune commande qui supprime des fichiers. De toute évidence, vous pouvez provoquer une perte de données avec cette commande, c'est ce que la commande a été conçue pour faire.

Comme d'autres réponses l'ont souligné, vous pouvez utiliser la ligne de commande pour rendre votre machine pratiquement inutilisable pendant un certain temps: vous pouvez arrêter sans confirmation, faire en sorte qu'un processus utilise 100% de vos ressources disponibles sans confirmation, tuer tous vos programmes. ou détruire votre système de fichiers. Si vous le souhaitez vraiment, vous pouvez utiliser la CLI pour créer une extension de noyau qui provoque la panique du noyau (ce qui est le plus proche d’un "crash" auquel je peux penser).

La ligne de commande (accessible via le terminal) est un outil puissant. Il est souvent plus rapide de résoudre un problème en utilisant Terminal que l’interface graphique. Certaines solutions ne sont disponibles qu’en utilisant les commandes Terminal. Cependant, la clé de la CLI est la compréhension . N'exécutez pas de commandes aléatoires que vous voyez en ligne. Lisez les pages de manuel et comprenez ce que font les commandes. Si vous n'êtes pas sûr, demandez à quelqu'un ou apprenez-en plus sur une commande avant de l'exécuter.

Josh
la source