Una forma de bloquear un equipo es ejecutar una llamada fork-bomb .

Puede ejecutarlo en un sistema Unix mediante:

:(){ :|: & };:

Es un comando que generará procesos de forma recursiva hasta que el sistema operativo esté tan ocupado que ya no responderá a ninguna acción.

No está seguro de lo que quiere decir acerca de 'bloquear' la computadora: si la redefiniera para que dijera 'inutilizable' para la computadora, entonces sí. Ciertamente, todo lo que se necesita es un comando que se desvía solo: solo un momento en el que no estás pensando con claridad sobre lo que estás haciendo, similar a cuando hablas sin pensar, y el daño puede ser inmenso y casi inmediato. El ejemplo clásico:

$ sudo rm -rf /

Si deja que el comando se ejecute por solo un segundo, puede eliminar lo suficiente de su sistema para que no pueda iniciarse y posiblemente causar una pérdida de datos irreversible. No lo hagas.

Suponga que no sabe lo que está haciendo e intenta hacer una copia de seguridad de algún disco duro

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

Bueno, si los mezcla (cambia si está activado), sobrescribirá los datos nuevos con datos antiguos, sin preguntas.

Mezclas similares pueden suceder con utils de archivo. Y, francamente, con la mayoría de las utilidades de línea de comandos.

Si desea un ejemplo de una combinación de un solo carácter que afecte su sistema, observe este escenario: desea mover todos los archivos del directorio actual a otro:

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

Aceptemos el hecho de que aprendiste a usar ./ para denotar el directorio actual. (Hago) Bueno, si omite el punto, comenzará a mover todos sus archivos. Incluyendo sus archivos de sistema. Tienes suerte de no haberte metido esto. Pero si lees en algún lugar que con 'sudo -i' nunca más tendrás que escribir sudo, estarás conectado como root ahora. Y ahora tu sistema se está comiendo frente a tus ojos.

Pero, de nuevo, creo que cosas como sobrescribir mis archivos de código precioso con basura, porque arruiné un carácter o porque confundí el orden de los parámetros, es más problemático.

Digamos que quiero revisar el código del ensamblador que gcc está generando:

gcc -S program.c > program.s

Supongamos que ya tenía un programa y uso la función TAB para completar. Tengo prisa y me olvido de TAB dos veces:

gcc -S program.c > program.c

Ahora tengo el código de ensamblador en mi programa.c y ya no tengo código c. Lo que es, al menos, un verdadero revés para algunos, pero para otros es un comienzo desde el principio.

Creo que estos son los que causarán un "daño" real. Realmente no me importa si mi sistema falla. Me importaría que mis datos se pierdan.

Desafortunadamente, estos son los errores que se deben cometer hasta que aprenda a usar el terminal con las precauciones adecuadas.

Causar un pánico en el kernel es más parecido a estrellarse que las otras respuestas que he visto aquí hasta ahora:

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

(código tomado de aquí y también se encuentra en la documentación propia de Apple )

También puedes probar:

sudo killall kernel_task

No he verificado que el segundo realmente funcione (y no tengo la intención de hacerlo, ya que tengo algunos trabajos abiertos en este momento).

MacOS moderno hace que sea realmente difícil bloquear tu máquina como usuario sin privilegios (es decir, sin usar sudo ), porque los sistemas UNIX están diseñados para manejar a miles de usuarios sin permitir que ninguno de ellos rompa el todo el sistema Por lo tanto, afortunadamente, por lo general, debe recibir una solicitud antes de hacer algo que destruya su máquina.

Lamentablemente, esa protección solo se aplica al sistema en sí. Como lo ilustra xkcd, hay muchas cosas que a usted le importa que no están protegidas por System Integrity Protection, privilegios de root o solicitudes de contraseña:

Entonces,hayunmontóndecosasquepuedesescribirquesoloarruinarántucuentadeusuarioytodostusarchivossinotienescuidado.Algunosejemplos:

• %código%.Estoparecetotalmenterazonable,hastaquetedascuentadequelavariabledeentornoestáescritarm-rf${TEMPDIR}/*.Porlogeneral,TMPDIRnoestádefinido,loquehacequeesteTEMPDIR.Inclusosinrm-rf/,estoeliminarácualquiercosaalaquetengapermisosdeeliminación,quegeneralmenteincluirátodasucarpetadeinicio.Sidejasqueestofuncionelosuficiente,tambiéndetendrácualquierunidadconectadaatumáquina,yaquegeneralmentetienespermisosdeescrituraparaesas.
• %código%.Porlogeneral,sudolocalizarálosarchivosquecumplanciertoscriteriosylosimprimirá.Sinelfind~-name"TEMP*" -o -print | xargs rm , esto hace lo que cabría esperar y elimina todos los archivos que comienzan con find ( siempre que no tenga espacios en la ruta ). Pero, -o significa "o" (¡no "salida" como lo hace con muchos otros comandos!), Lo que hace que este comando elimine realmente todos sus archivos. Bummer.
• %código%. De vez en cuando me equivoco con la sintaxis de este comando, y con mucho gusto sobrescribirá su archivo importante con un enlace simbólico inútil.
• TEMP* eliminará cada uno de sus programas, lo desconectará rápidamente y posiblemente causará la pérdida de datos.

Otro que puedes hacer (que he hecho antes por error) es:

sudo chmod 0 /

Esto hará que todo el sistema de archivos (lo que significa que todos los comandos y programas) sea inaccesible ... excepto por el usuario root. Esto significa que necesitará iniciar sesión directamente como usuario root y restaurar el sistema de archivos, PERO no puede acceder al comando sudo (o cualquier otro comando, para el caso). Puede restaurar el acceso a comandos y archivos iniciando en modo de usuario único, montando y restaurando el sistema de archivos con chmod 755 / .

Si esto se hace recursivamente con chmod -R 0 / , entonces el sistema quedará inutilizable. La solución adecuada en ese momento es usar la Utilidad de Disco de la partición de recuperación para reparar permisos de disco . Es posible que esté mejor para restaurar una instantánea o copia de seguridad de su sistema de archivos si esto se ejecutó recursivamente.

Las respuestas que llaman a sudo deben considerarse inválidas. Estos ya asumen Acceso administrativo al sistema.

Prueba perl -e 'exit if fork;for(;;){fork;}' . OSX puede tener alguna protección contra esto ahora. Si se presenta una burbuja de manzana que le pregunta si desea finalizar la aplicación de Terminal y los subprocesos, está (casi) bien.

while true ; do cat /dev/zero > /dev/null & done también es muy útil, esp. si no tienes perl .

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & done solo hará una pequeña prueba divertida de carga de CPU. Muy bueno para comprobar si su disipador térmico y su ventilador están a la par.

Claro, asegúrate de tener una copia de seguridad y guarda los archivos que te interesan, luego escribe halt

Suponiendo que luego usas sudo para ser root, la Mac se bloqueará.

El mayor riesgo de la línea de comandos es la pérdida de datos. La interfaz macOS está diseñada durante décadas para no sorprender a las personas y destruir sus datos o configuraciones o aplicaciones. La interfaz gráfica de macOS también existe para eliminar la curva de aprendizaje (una pronunciada) para estar seguro y dominar los scripts de shell.

Se pierden esas protecciones, por lo que les advierto a las personas que comienzan con la aplicación de terminal o ssh. Si tiene una copia de seguridad que sabe que funciona y tiene el tiempo y la confianza / habilidad para realizar una restauración, entonces debe sumergirse y aprender e incluso romper cosas.

sudo kill -9 -1  

Accidentalmente realicé un kill -9 -1 en un script perl, ejecutando como root. Eso fue tan rápido, como tirar del cable de alimentación. Al reiniciar, el servidor realizó una comprobación del sistema de archivos y continuó ejecutándose correctamente.

Nunca probé el comando sudo kill -9 -1 en la línea de comandos. Puede que no funcione, porque el identificador de proceso "-1" significa "eliminar todos los procesos que pertenecen al grupo de procesos de la persona que llama".

No estoy seguro, si con sudo, eso también significa init y todas las cosas del kernel ... Pero si eres root, kill -9 -1 definitivamente se detendrá de inmediato, como si tirásemos del cable de alimentación. Por cierto, ¡nada aparecerá en los archivos de registro, porque ese comando es el asesino más rápido en el oeste!

En realidad, para recuperarme, fui a nuestros administradores de sistemas y les dije lo que hice. Hicieron un reinicio difícil, porque no había manera de iniciar sesión en ese servidor (RHEL6).

Un kill -9 -1 como root mata todos los procesos, que se ejecutan como root. Eso es, por ejemplo, sshd. Eso me desconectó inmediatamente e impidió que alguien volviera a iniciar sesión. Cualquier proceso iniciado por init, incluido init, se ha eliminado, a menos que hayan cambiado UID o GID. Incluso el inicio de sesión a través de la consola serie ya no era posible. ps -eaf | grep root muestra algunos procesos sofisticados que, si reaccionan en un SIGKILL de forma predeterminada, detendrían la escritura básica en HD.

No intentaré esto ahora en mi computadora portátil :-) No tengo la curiosidad de saber si un kill -9 165 ([ext4-rsv-conver]) realmente dejaría de escribir en el HD.

Sí, puedes destruir completamente tu sistema. Accidentalmente hacer algo con los privilegios sudo es un ejemplo que se ha publicado, ya sea olvidando algunos caracteres que indican al terminal que haga algo completamente diferente de lo que usted quería. rm ing / en lugar de /tmp/\* es solo una diferencia de 5 caracteres. Poner un espacio en el lugar equivocado también podría hacer algo completamente diferente. Otras veces, las instrucciones aparentemente bien intencionadas podrían tener un código malicioso oculto en él. Algunas personas en Internet son muy buenas para ofuscar el código.

También hay comandos que, mediante el uso de html, se puede convertir en tamaño de fuente cero, por lo que, al ser copiado en el portapapeles, algo que puede parecer completamente inocuo podría ser, de hecho, instalar el repositorio git de alguien como una fuente confiable y descargar malware.

Y hay comandos que puedes ejecutar que te abren para explotar, o que podrían estar perfectamente bien diseñados pero elimina archivos o programas importantes o corrompe tu disco. De hecho, el uso incorrecto de las herramientas podría hacer algo tan básico como escribir accidentalmente sobre su sector de arranque, el encabezado de su disco o muchos otros problemas.

Un ejemplo de algo menos destructivo que no se ha publicado es abrir archivos binarios en vi . Si alguna vez lo has probado, sabrás que puede arruinar tu terminal hasta el punto de que no se pueda usar hasta que sea reset .

Alternativamente, hay comandos que atascarán su máquina, como:

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

Puedes probar eso, no va a hacer daño, pero atascará tu procesador y tendrás que terminar cada proceso que hayas generado.

Dicho esto, en la computación generalmente se considera que no se puede hacer una tortilla sin romper algunos huevos. Debes ser cauteloso en la terminal, pero la única forma de mejorar el uso del sistema operativo es aprendiendo y practicando.

Sólo soy un principiante de bash, pero puedes establecer un tiempo True; hacer comando; hecho; La mayoría de las personas intentaría Ctrl + C que detendrá el comando, no el proceso externo (ctrl + Z, que luego debe eliminarse). Supongo que si el comando es una operación pesada como multiplicar un gran número a su propio poder, eso podría interferir con tus recursos. Pero, de hecho, los sistemas operativos modernos generalmente están protegidos contra tal desorden.

Es un poco ambiguo lo que quieres decir con "bloquear" tu computadora ... y no hay una respuesta correcta definitiva para eso, aunque hay algunos ejemplos útiles en otras respuestas. Dado que su pregunta es más ambigua y general, me gustaría centrarme en la naturaleza de la pregunta y dar una respuesta más general.

  

Las personas que no entienden el terminal a menudo tienen miedo de usarlo por temor a que puedan estropear su comando y bloquear su computadora

Creo que la línea de comando es una espada de doble filo y, a menudo, muy aguda. Su mayor fortaleza es también su mayor debilidad para los nuevos usuarios: los programas CLI hacen lo que usted dice, sin preguntar si realmente es lo que quería decir. A menudo no piden confirmación, no proporcionan ayuda de mano o interactiva, y sus opciones son breves, a menudo concisas, a veces confusas en cadenas de texto. Tenga en cuenta que están generalmente muy bien , uno solo tiene que leer el manual (que casi siempre es man <command you are about to run> ) y tomarse el tiempo para entender cuál es la línea de comandos vamos a correr lo haremos.

Este modo de operación es poderoso : significa que los usuarios experimentados de CLI pueden crear "tuberías" de comandos largas que realizan tareas complejas con comandos individuales. Esto se debe a que la tarea no preguntará "¿Estás seguro?" A cada paso del camino, hace lo que se dice. Pero para un usuario que no esté familiarizado con este modo, y que esté acostumbrado a una GUI donde la ayuda en línea está a un clic , no está familiarizada y da miedo.

  

¿Pero en realidad hay comandos que bloquearán tu computadora?

¿Puede "bloquear" su computadora usando la CLI? Tal vez. Ciertamente puede causar pérdida de datos si usa un comando destructivo incorrectamente. P.EJ. Muchas de las respuestas aquí mencionan rm , un comando que elimina archivos. Obviamente, puede causar la pérdida de datos con ese comando, es para lo que se diseñó el comando.

Como han señalado otras respuestas, puede usar la línea de comandos para hacer que su máquina sea virtualmente inutilizable por un período de tiempo: puede apagar sin confirmación, provocar que un proceso utilice el 100% de sus recursos disponibles sin confirmación, matar Todos sus programas o destruir su sistema de archivos. Si realmente quisiera, podría usar el CLI para crear una extensión del kernel que cause un pánico en el kernel (que es el más cercano a un "bloqueo" que se me ocurre).

La línea de comando (a la que se accede a través del terminal) es una herramienta poderosa. A menudo es más rápido resolver un problema usando Terminal que la GUI. Algunas soluciones solo están disponibles usando comandos de Terminal. Sin embargo, la clave para el CLI es entender . No ejecute comandos aleatorios que vea en línea. Lee las páginas del manual y entiende lo que hacen los comandos. Si no está seguro, pregunte a alguien u obtenga más información sobre un comando antes de ejecutarlo.

Seguramente todavía puede causar una falla del sistema al usar los comandos ingresados con el Terminal.

Con los años, es cada vez más difícil, probablemente debido a todo tipo de límites y medidas de protección aplicadas, pero como dice la ley de Murphy: "Nada es infalible para un tonto suficientemente capaz".

Las "bombas de bifurcación" y todas esas cosas de rm -rf script kiddies son cosas antiguas conocidas para UNIX. Con Mac OS X, puede divertirse más utilizando sus partes del subsistema GUI ( WindowServer para mencionar) o algo así como el firewall OpenBSD también conocido como PF que los ingenieros de Apple incorporaron pero nunca lograron actualizar desde su estado de cosas en 2008. PF funciona en el kernel, por lo que, cuando detecta un capricho, es hora de que Apple le diga " usted reinició la computadora debido a un pánico" o algo así.

La peor parte de esto es que nunca puedes tener una idea de dónde y por qué entró en pánico ...  porque Apple no proporciona ningún rastro de pila significativo; solo puede tener números hexadecimales de las direcciones de retorno del marco de pila.