Você pode realmente usar o Terminal para travar o seu computador?

48

As pessoas que não entendem o Terminal geralmente têm medo de usá-lo por medo de atrapalhar o comando e travar o computador. Quem conhece o Terminal sabe que esse não é o caso - geralmente o Terminal apenas gera um erro. Mas, na verdade, existem comandos que irão travar seu computador?

AVISO: você pode perder dados se digitar ou copiar e colar, especialmente sudoe rmcomandos.

DonielF
fonte
Um cara acidentalmente limpou todos os computadores da empresa em uma linha. Vi-o neste site há alguns anos, era falso, mas ainda podia acontecer facilmente. Vou ligar se puder encontrá-lo.
Noah Cristino
7
O Terminal é apenas uma interface de linha de comando para a execução de programas. É uma alternativa a uma interface gráfica do usuário . Você pode executar programas arbitrários de qualquer um deles. Sua pergunta, portanto, não faz muito sentido; em vez disso, você deve perguntar: Você pode travar o computador executando um programa?
Jamesdlin #
O que você quer dizer com "acidente"? Os comandos executados no terminal geralmente podem ser poderosos e geralmente "fazem o que você diz e não o que você quer dizer" sem perguntar, ao contrário da maioria dos comandos da GUI do Mac OS X. Mas, a menos que você tente intencionalmente , é improvável que você bata na máquina. (Eu posso pensar de algumas maneiras de fazê-lo intencionalmente no entanto)
Josh
11
Colar comandos na web pode ser muito perigoso . Independentemente da possibilidade de pendurar sua máquina. Digitar comandos que você entende pelo menos vagamente não deve ser perigoso. Caso contrário, várias maneiras de danificar seu computador. É como clicar em definições de configuração aleatórias do sistema na GUI, mas na GUI pelo menos as possibilidades são mais limitadas. wrt o perigo de colar comandos - o texto que você visualiza copiado visualmente pode ser diferente do texto copiado real, portanto, pode conter comandos maliciosos misturados.
#
@ иσαнcяişтiпσ Talvez serverfault.com/questions/769357/recovering-from-a-rm-rf
wythagoras

Respostas:

51

Uma maneira de travar um computador é executar a chamada bomba de forquilha .

Você pode executá-lo em um unix-sytem:

:(){ :|: & };:

É um comando que gera recursivamente processos até que o sistema operacional esteja tão ocupado que não responda mais a nenhuma ação.

Rick van Hal
fonte
49
@bunyaCloven Se eu entendo seu comando corretamente, é um comando para remover todas as pastas sem avisar , o que é muito perigoso se funcionar . Eu gostaria que você escrevesse um aviso para isso.
Andrew T.
80
@AndrewT. As pessoas não devem apenas digitar comandos aleatórios que encontraram na Internet, todos à vontade. (especialmente aqueles em uma linha chamada "você pode travar o seu computador via terminal")
John Hamilton
34
O OP pediu um acidente no terminal, não uma limpeza.
piersb
16
A bomba de garfo realmente causará danos mínimos no Mac OS X, pois possui limites superiores para o número de processos.
GDP2 31/07
7
O @bunyaCloven substitui o ;por um &e você remove todos os arquivos e o fork bomb ao mesmo tempo e vê o que interrompe o sistema primeiro!
Muzer
41

Não sei o que você quer dizer com 'travar' o computador - se você o reformular para dizer 'tornar o computador inutilizável', então sim. Certamente, basta um único comando perdido - apenas um momento em que você não está pensando claramente sobre o que está fazendo, semelhante a quando você fala sem pensar, e o dano pode ser imenso e quase imediato. O exemplo clássico:

$ sudo rm -rf /

Se você deixar esse comando ser executado por apenas um segundo, isso pode acabar com o sistema suficiente para torná-lo não inicializável e possivelmente causar perda irreversível de dados. Não faça isso.

Harv
fonte
2
E apenas para compartilhar por que eu quis esclarecer a reformulação ... para 'travar' o computador no sentido tradicional - para travá-lo - você precisaria dar à CPU trabalho suficiente para que ela não possa responder em tempo hábil para outros trabalhos. como atualizar os gráficos e mover o cursor, por exemplo. Tenho certeza de que há uma maneira de fazer isso na linha de comando.
Harv 31/07
6
@DonielF -rsignifica excluir recursivamente os arquivos em um diretório. -fsignifica "forçar", como em não pedir confirmação, independentemente das permissões de um determinado arquivo. /é o diretório raiz do sistema de arquivos, o que significa que ele destruirá tudo e qualquer coisa, exceto talvez alguns arquivos especiais que não se comportam como arquivos típicos. Além disso, você terá muita dificuldade em encontrar um breve comando que trava o sistema sem permissões de administrador / root.
GDP2 31/07
11
Eu tentei rm -rf /um tempo atrás e rmdisse que, se você deseja remover a raiz, use esse sinalizador. Nenhum dado foi perdido. Parece que agora existe uma proteção de segurança contra a execução cega rm -rf /.
Alexyorke
27
bandeira --no-preserve-root foi exigida desde 2006 para que isso funcione como pretendido
Encaitar
6
Aqui é um caso real em que isso realmente aconteceu - um rm -rf realmente semelhante a um legal, que foi realmente errado: /
mgarciaisaia
30

Suponha que você não saiba o que está fazendo e tentando fazer backup de algum disco rígido

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

Bem, se você misturá-los (alterne se e de), ele substituirá os dados novos por dados antigos, sem perguntas.

Podem ocorrer misturas semelhantes com os utilitários de arquivo. E, francamente, com a maioria dos utilitários de linha de comando.

Se você deseja um exemplo de uma mistura de um caractere que trava o sistema, observe este cenário: Você deseja mover todos os arquivos no diretório atual para outro:

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

Vamos aceitar o fato de que você aprendeu a usar ./para denotar o diretório atual. (Sim) Bem, se você omitir o ponto, ele começará a mover todos os seus arquivos. Incluindo os arquivos do sistema. Você tem sorte de não ter sudo isso. Mas se você ler em algum lugar que, com 'sudo -i', nunca mais precisará digitar sudo, pois você está logado como root agora. E agora seu sistema está se alimentando diante de seus próprios olhos.

Mas, novamente, acho que coisas como sobrescrever meus preciosos arquivos de código com lixo, porque errei um caractere ou porque misturei a ordem dos parâmetros, são mais problemas.

Digamos que eu queira verificar o código do assembler que o gcc está gerando:

gcc -S program.c > program.s

Suponha que eu já tenha um program.s e use a conclusão do TAB. Estou com pressa e esqueça o TAB duas vezes:

gcc -S program.c > program.c

Agora eu tenho o código do assembler no meu program.c e não tenho mais o código c. O que é pelo menos um verdadeiro revés para alguns, mas para outros é começar do zero.

Eu acho que esses são os que causam "danos" reais. Eu realmente não me importo se meu sistema travar. Eu me importaria com a perda de meus dados.

Infelizmente, esses são os erros que deverão ser cometidos até você aprender a usar o terminal com as devidas precauções.

MrPaulch
fonte
16
Seu último ponto é uma das muitas razões pelas quais todos devem usar o controle de versão
Darren H
4
Certa vez, destruí um programa em que estava trabalhando, gcc program.c -o program.cgraças exatamente à conclusão da guia. Aprendi a usar o controle de versão religiosamente depois disso.
Nneonneo 01/08/19
2
A melhor resposta até agora, postando comandos com aparência legítima que podem resultar de um simples erro de digitação e, no entanto, podem resultar em um grande dano.
precisa saber é o seguinte
11
"Agora eu tenho o código assembler no meu program.c" Não. Você não tem nada. O redirecionamento truncou o arquivo antes mesmo que o GCC o abrisse.
Muru
11
Oh, cara, eu estou realmente feliz por eles terem adicionado essa melhoria na interface do usuário no GCC. Já faz um tempo desde o meu último erro, mas é bom ver que vou ter um pouco de proteção contra isso da próxima vez.
Nneonneo 6/08
28

Causar um pânico no kernel é mais parecido com o travamento do que as outras respostas que eu vi aqui até agora:

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

(código retirado daqui e também encontrado na documentação da Apple )

Você também pode tentar:

sudo killall kernel_task

Eu não verifiquei se o segundo realmente funciona (e não pretendo, pois tenho algum trabalho aberto no momento).

PIB2
fonte
2
Apenas tentei o segundo em uma VM 10.12.3, e ele apenas diz:No matching processes were found
Alexander O'Mara
3
Além disso, o primeiro não parece trabalho, pelo menos, se SIP está habilitada,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 Não estou muito surpreso com seus resultados no segundo comando; Imaginei que o Mac OS X não permitiria que você simplesmente derrubasse o processo do kernel dessa maneira. Os resultados do primeiro comando também são esperados, como dtracefoi efetivamente neutralizado pelo SIP.
GDP2 31/07
11
kernel_tasknão é um processo normal. É imortal; Ele não pode ser eliminado, exceto por um erro próprio (e isso seria chamado de KP e derrubaria toda a máquina). kernel_taskO PID é nominalmente 0, mas se você fornecer isso ao kill(pid, sig)syscall, a página de manual diz que Se for pidigual a 0, sigserá enviada a todos os processos no grupo de processos do processo de chamada. . Portanto, você simplesmente não consegue enviar kernel_taskum sinal.
Iwillnotexist Idonotexist
@IwillnotexistIdonotexist Sim, imaginei que seria o caso; obrigado pela informação, no entanto. Coisas boas a ter em mente.
GDP2 31/07/19
19

O macOS moderno torna muito difícil travar sua máquina como um usuário sem privilégios (ou seja, sem usar sudo), porque os sistemas UNIX destinam-se a lidar com milhares de usuários sem permitir que nenhum deles quebre o sistema inteiro. Portanto, felizmente, você precisará ser avisado antes de fazer algo que destrua sua máquina.

Infelizmente, essa proteção se aplica apenas ao próprio sistema. Como o xkcd ilustra, há muitas coisas importantes para você que não são protegidas pelo System Integrity Protection, privilégios de root ou solicitações de senha:

XKCD 1200

Portanto, existem várias coisas que você pode digitar que acabarão com a sua conta de usuário e todos os seus arquivos, se você não tomar cuidado. Alguns exemplos:

  • rm -rf ${TEMPDIR}/*. Isso parece totalmente razoável, até você perceber que a variável de ambiente está escrita TMPDIR. TEMPDIRgeralmente é indefinido, o que torna isso rm -rf /. Mesmo sem sudo, isso removerá com prazer qualquer coisa para a qual você tenha permissões de exclusão, que geralmente inclui toda a sua pasta pessoal. Se você deixar isso funcionar por tempo suficiente, também danificará qualquer unidade conectada à sua máquina, já que você geralmente tem permissões de gravação para elas.
  • find ~ -name "TEMP*" -o -print | xargs rm. findnormalmente localizará arquivos que correspondem a determinados critérios e os imprimirá. Sem -oisso, o que você esperaria e exclui todos os arquivos iniciados TEMP*( desde que você não tenha espaços no caminho ). Mas, os -omeios "ou" (não "saída", como acontece com muitos outros comandos!), Fazendo com que este comando realmente exclua todos os seus arquivos. Vadio.
  • ln -sf link_name /some/important/file. Ocasionalmente, recebo a sintaxe errada deste comando e ele substitui o arquivo importante com um link simbólico inútil.
  • kill -9 -1 irá matar todos os seus programas, desconectando você rapidamente e possivelmente causando perda de dados.
nneonneo
fonte
3
FYI (para os outros que lêem este) findtem um -deleteargumento que é muito mais seguro do que a tubagem axargs rm
Josh
O MacOS moderno é realmente mais resistente a colisões? A maioria desses sistemas é para um único usuário. Eles realmente têm maxprocs / cpulimits sãos? Você pode fornecer uma referência?
precisa saber é o seguinte
11
Você, de todas as pessoas, saberia bem o dano ln -sfpode fazer ... e como recuperar a partir dele :-)
Iwillnotexist Idonotexist
11
@ Josh: obrigado por apontar isso. E, no caso geral, deve-se usar find -print0 | xargs -0para manipular com segurança caracteres estranhos nos nomes de arquivos.
Nneonneo 3/08
11
Acordado. Mais conselhos úteis do xargs: use <whatever> | xargs echo <something>primeiro, para visualizar quais comandos o xargs realmente executará. O xargs é um ótimo exemplo de por que a CLI é tão poderosa: você pode operar em muitos, muitos itens ao mesmo tempo, sem a confirmação incômoda e a manipulação manual ... apenas certifique-se de dizer para fazer o que quiser.
21717 Josh
16

Outro que você pode fazer (que eu já fiz por engano antes) é:

sudo chmod 0 /

Isso tornará todo o seu sistema de arquivos (o que significa todos os comandos e programas) inacessível ... exceto pelo usuário root. Isso significa que você precisaria efetuar login diretamente como usuário root e restaurar o sistema de arquivos, MAS não poderá acessar o sudocomando (ou qualquer outro comando, nesse caso). Você pode restaurar o acesso a comandos e arquivos inicializando no modo de usuário único, montando e restaurando o sistema de arquivos chmod 755 /.

Se isso for feito recursivamente chmod -R 0 /, isso tornará o sistema inutilizável. A correção adequada nesse momento é usar o Utilitário de Disco da partição de recuperação para reparar permissões de disco . Pode ser melhor apenas restaurar um instantâneo ou backup do seu sistema de arquivos, se este for executado de forma recursiva.

musicman523
fonte
8
"Você pode consertar isso ... chmod 755 /" - Não, você não pode. Muitos arquivos requerem permissões diferentes de 755, por segurança ou para funcionar. chmod 755 /deixará seu sistema inseguro e quebrado de maneiras sutis. A única recuperação completa chmod 0 /é através da restauração de instantâneo, restauração de backup e / ou reinstalação.
Marcelm 01/08
2
@marcelm Bom ponto. Minha sugestão foi apenas restaurar o acesso aos comandos, não como uma correção permanente. Atualizei minha resposta para refletir isso. Até onde eu sei, o chmod não é recursivo a menos que você use o -Rsinalizador - então pensei que as permissões dos subdiretórios não seriam afetadas?
musicman523
5
@ marcelm, você está certo, mas o comando mostrado não é recursivo, apenas /é afetado.
Andrea Lazzarotto
Eu já fui sudo chmod -R 700 /um computador novo, imaginando que seria muito mais seguro se eu fizesse isso. Surpreendentemente, ele inicializou e acabou com uma barra de menus vazia e uma área de trabalho em branco. Nada mais funcionou, mas as Permissões de Restauração de Utilitário de Disco da partição de recuperação conseguiram definir quase tudo certo!
Nneonneo 1/08
2
utility @marcelm Disk tem uma opção "Fix permissões" que deve corrigir isso sem uma restauração completa do sistema
Josh
10

As respostas dessa chamada sudodevem ser consideradas inválidas. Eles já assumem acesso administrativo ao sistema.

Tente perl -e 'exit if fork;for(;;){fork;}'. O OSX pode ter alguma proteção contra isso agora. Se for apresentado um balão de maçã perguntando se você deseja finalizar o aplicativo e subprocessos do Terminal, você é (quase) bom.

while true ; do cat /dev/zero > /dev/null & donetambém é muito útil, esp. se você não tiver perl.

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & doneapenas fará um pequeno teste de carga de CPU engraçado. Muito bom para verificar se o dissipador de calor e o ventilador estão no mesmo nível.

user2497
fonte
Isso é conhecido como Fork Bomb e provavelmente tornará o sistema inutilizável (pode ser considerado um "acidente"), mas provavelmente não causará danos permanentes. Mas é desagradável!
217 Josh
@ Josh ", mas provavelmente não causará nenhum dano permanente" Exceto por qualquer trabalho não salvo atualmente aberto.
precisa
@reirab Josh adicionou o catch-all 'provável' à sua declaração. Mas o MacOS é principalmente para editar fotos e vídeos agora. Os programas da Adobe não têm salvamento automático?
user2497
11
Além disso, o trabalho não salvo está sempre em risco até ser salvo. Se o seu computador está inutilizada, então você não pode salvar qualquer coisa que você tem aberto :)
Josh
@ Jososh MacOS é tão fácil de guardar coisas. É sempre 🍎-S. Você não deveria ter escrito 'provável' 👋🏾
user2497
7

Claro, verifique se você possui um backup, salve os arquivos de que gosta e digite halt

Supondo que você sudoseja root, o Mac falhará.

O maior risco da linha de comando é a perda de dados. A interface do macOS foi projetada ao longo de décadas para não surpreender as pessoas e destruir seus dados, configurações ou aplicativos. A interface gráfica do macOS também existe para remover a curva de aprendizado (uma íngreme) para ser segura e dominar os scripts de shell.

Você perde essas proteções e é por isso que aconselho as pessoas que começam com app terminal ou ssh. Se você tem um backup que você sabe que funciona e tem tempo e confiança / habilidade para executar uma restauração, deve se aprofundar, aprender e até quebrar as coisas.

bmike
fonte
3
Você disse: "... e até quebra coisas", que é um bom caso de uso para fazer coisas arriscadas em uma máquina virtual. :)
user3439894
11
Como isso vai falhar? Apenas desliga o sistema imediatamente. Ele até libera os buffers do kernel, para que não haja perda de dados (salva). developer.apple.com/legacy/library/documentation/Darwin/…
Josh
7
sudo kill -9 -1  

Eu acidentalmente executei um kill -9 -1em um script perl, executando como root. Isso foi tão rápido quanto puxar o cabo de força. Na reinicialização, o servidor fez uma verificação do sistema de arquivos e continuou funcionando corretamente.

Eu nunca tentei esse sudo kill -9 -1comando na linha de comando. Pode não funcionar, porque o ID do processo "-1" significa "eliminar todos os processos que pertencem ao grupo de processos do chamador".

Não tenho certeza, se com sudo, isso também significa init e todo o material do kernel ... Mas se você é root, kill -9 -1definitivamente fará uma parada imediata - assim como puxar o cabo de alimentação. A propósito - nada aparecerá nos arquivos de log, porque esse comando é o assassino mais rápido do oeste!

Na verdade, para me recuperar, fui aos nossos administradores de sistemas e contei o que fiz. Eles fizeram uma reinicialização forçada, porque não havia como fazer login no servidor (RHEL6).

A kill -9 -1como raiz mata todos os processos, que são executados como raiz. Ou seja, sshd. Isso me desconectou imediatamente e impediu que alguém fizesse login novamente. Qualquer processo iniciado pelo init, incluindo o init, foi eliminado, a menos que eles alterassem o UID ou o GID. Mesmo o login através do console serial não era mais possível. ps -eaf | grep rootmostra alguns processos sofisticados, que, se eles reagirem a um SIGKILL da maneira padrão, praticamente impedirão a gravação básica em HD.

Não vou tentar isso agora no meu laptop :-) Não tenho curiosidade suficiente para descobrir se um kill -9 165([ext4-rsv-convert]) realmente pararia de gravar no HD.

bubi6608
fonte
Você não pode "matar" o kernel, e isso não deve causar um check-in do sistema de arquivos. Como você se recuperou da situação? Você fez uma reinicialização completa? Porque isso é provavelmente o que causou a verificação do sistema de arquivos :)
Josh
Sua resposta editada faz sentido. Você não pode realmente matar initnormalmente, mas pode matar todas as sessões gettys e SSH e tornar a máquina inutilizável. A mágica SysRq deveria ter permitido para uma reinicialização limpa, mas muitas vezes é mais fácil de ciclo de energia justo e contar com a revista FS :)
Josh
5

Sim, você pode destruir completamente o seu sistema. Fazer algo acidentalmente com sudoprivilégios é um exemplo que foi publicado, seja esquecendo alguns caracteres que instruem o terminal a fazer algo completamente diferente do que você pretendia. rming em /vez de /tmp/\*é apenas uma diferença de 5 caracteres. Colocar um espaço no lugar errado também poderia fazer algo completamente diferente. Outras vezes, instruções aparentemente bem-intencionadas poderiam ter ocultado um código malicioso. Algumas pessoas na internet são muito boas em ofuscar código.

Também existem comandos que, usando html, podem ser tornados zero o tamanho da fonte, para que algo completamente inócuo, quando copiado para a área de transferência, possa de fato estar instalando o repositório git de alguém como uma fonte confiável e fazendo o download de malware.

E existem comandos que você pode executar que o abrem para serem explorados, ou que poderiam ser perfeitamente bem-intencionados, mas removem arquivos ou programas importantes ou corrompem seu disco. De fato, o uso incorreto de ferramentas pode fazer algo tão básico quanto escrever acidentalmente em seu setor de inicialização, na cabeça do seu disco ou em muitos outros problemas.

Um exemplo de algo menos destrutivo que não foi publicado é a abertura de arquivos binários vi. Se você já experimentou, saberá que ele pode atrapalhar o seu terminal a ponto de ser inutilizável até que seja reset.

Como alternativa, existem comandos que atolarão sua máquina, como:

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

Você pode tentar esse, não vai causar danos, mas atrapalha o seu processador, e você terá que matar cada processo que gerou.

Dito isto, na computação é geralmente considerado que você não pode fazer uma omelete sem quebrar alguns ovos. Você deve ser cauteloso no terminal, mas a única maneira de melhorar o uso do sistema operacional é aprendendo e praticando.

JFA
fonte
Seu primeiro exemplo não é prejudicial. O Vim é realmente bastante sensato ao editar arquivos binários. E no pior dos casos, você pode simplesmente fechar a janela. O segundo exemplo com "yes" é irritante e consumirá bastante CPU do usuário, mas o sistema permanecerá responsivo e você poderá facilmente matar a janela do terminal pai.
Nneonneo 2/08
11
Eu discordo de "atrapalhe seu terminal a ponto de não poder usá-lo até que você reinicie" - tente reset, isso deve limpar um terminal que tenha uma saída binária impressa nele. ou, simplesmente gerar um novo TTY
Josh
11
Legal, nw @JFA. Na verdade, levei anos para aprender o resettruque! Para obter mais informações: unix.stackexchange.com/questions/79684
Josh
11
@ Josh obrigado por isso, foi uma grande ajuda. Realmente faz muitos anos para mim: P
JFA
11
@ Josh Então 'stty sane ^ M' e 'tput reset' também devem ser empolgantes para você.
precisa saber é o seguinte
4

Eu sou apenas um iniciante no bash, mas você pode definir um tempo como True; COMMAND; feito; A maioria das pessoas tentaria Ctrl + C que interromperá o comando, não o processo externo (ctrl + Z, que precisa ser eliminado). Eu acho que se o comando é uma operação pesada, como multiplicar um grande número pelo seu próprio poder, isso pode prejudicar seus recursos. Mas, de fato, o sistema operacional moderno geralmente está protegido contra essa bagunça.

Ando Jurai
fonte
2
Ele roda muito rápido, não trava nada. Você só precisa fazer alguns cálculos intensivos para que o maxprocs do kernel não fique triste. tentewhile true do cat /dev/zero > /dev/null & done
user2497
obrigado. Eu esperava que lidar com grandes números para tornar o computador lento, às vezes acontecia com programas java / python muito simples que eu usava para aprendizado de máquina.
Ando Jurai
11
O bit zero a nulo cat é uma operação de grande número, pelo menos em E / S. Eu uso um desses por núcleo de uma CPU para fazer testes térmicos.
user2497
11
E ^C também matará o loop while, mas ele se repete muito rápido para que a interrupção seja capturada. Manter pressionado ^Cpode sair do circuito. Fechando o terminal também vai :)
Josh
2
@ Josh É mais fácil capturar o INT se houver uma pequena pausa, como o sono 0,1, após a tarefa intensiva da CPU.
user2497
3

Certamente você ainda pode causar uma falha no sistema usando os comandos inseridos no Terminal.

Com o passar dos anos, está ficando mais difícil, provavelmente devido a todos os tipos de limites e medidas de proteção aplicadas, mas como a lei do tipo Murphy declara: "Nada é infalível para um tolo suficientemente capaz".

"Fork bombs" e todo esse rm -rfmaterial infantil de script são coisas conhecidas do UNIX. Com o Mac OS X, você pode se divertir mais usando as partes do subsistema da GUI ( WindowServerpara mencionar) ou algo como o firewall do OpenBSD, também conhecido PFpelos engenheiros da Apple, mas que nunca conseguiram atualizar desde o estado de coisas de 2008. PFfunciona no kernel; portanto, quando ele percebe uma peculiaridade, é hora da Apple dizer " você reiniciou o computador devido a um pânico" ou coisas assim.

A pior parte disso é que você nunca pode ter uma idéia de onde e por que entrou em pânico - porque a Apple não fornece nenhum rastreamento significativo de pilha; você pode ter apenas números hexadecimais dos endereços de retorno do quadro da pilha.

poige
fonte
Boa resposta e excelentes pontos. Eu gostaria de adicionar à sua lista de boas maneiras de fazer com que o OS X entre em pânico na pista de dança, meu favorito pessoal, mas sem termos explícitos para evitar as estupidez dos pequenos. Descarrego uma extensão do kernel relevante para a NFC. Funciona sempre, instantaneamente. Pode-se facilmente colocar isso em um DOS, agendando-o em um número divisível de 5 minutos. Portanto, ele inicializa e depois mergulha o cisne. Isto requer uma reinstalação do sistema operacional dada a maioria dos administradores e até mesmo técnicos vai perder isso ....
Francis de ResponseBase
3

É um pouco ambíguo o que você quer dizer com "travar" seu computador ... e não há resposta correta definitiva para isso, embora haja alguns exemplos úteis em outras respostas. Como sua pergunta é mais ambígua e geral, gostaria de focar na natureza da pergunta e fornecer uma resposta mais geral.

As pessoas que não entendem o Terminal geralmente têm medo de usá-lo por medo de atrapalhar o comando e travar o computador.

Eu acho que a linha de comando é uma faca de dois gumes, e muitas vezes muito afiada. Sua maior força também é sua maior fraqueza para novos usuários: os programas CLI fazem o que você diz, sem perguntar se é realmente o que você quis dizer. Geralmente, eles não pedem confirmação, não fornecem ajuda interativa ou de mãos dadas e suas opções são curtas, muitas vezes concisas, às vezes confusas. Observe que eles geralmente são muito bem documentados, basta ler o manual (o que é quase sempre man <command you are about to run>) e dedicar um tempo para entender o que a linha de comando que eles executarão fará.

Esse modo de operação é poderoso - significa que os usuários experientes da CLI podem criar "pipelines" de comando longos, que executam tarefas complexas com comandos únicos. Isso ocorre porque a tarefa não pergunta "Você tem certeza?" a cada passo do caminho, ele faz o que é dito. Porém, para um usuário não familiarizado com esse modo e acostumado a uma GUI em que a ajuda on-line está a um clique de distância, isso é desconhecido e assustador.

Mas, na verdade, existem comandos que irão travar seu computador?

Você pode "travar" seu computador usando a CLI? Talvez. Você certamente pode causar perda de dados se você usar um comando destrutivo incorretamente. Por exemplo, muitas das respostas mencionadas aqui rm, um comando que exclui arquivos. Obviamente, você pode causar perda de dados com esse comando, é para isso que o comando foi projetado.

Como outras respostas apontaram, você pode usar a linha de comando para tornar sua máquina praticamente inutilizável por um período de tempo: você pode desligar sem confirmação, fazer com que um processo use 100% dos recursos disponíveis sem confirmação, matar todos os seus programas ou destrua seu sistema de arquivos. Se você realmente quisesse, poderia usar a CLI para criar uma extensão do kernel que causasse pânico no kernel (que é o mais próximo de um "travamento" em que consigo pensar).

A linha de comando (acessada através do Terminal) é uma ferramenta poderosa. Muitas vezes, é mais rápido resolver um problema usando o Terminal do que a GUI. Algumas soluções estão disponíveis apenas usando os comandos do Terminal. No entanto, a chave para a CLI é o entendimento . Não execute comandos aleatórios que você vê online. Leia as páginas de manual e entenda o que os comandos fazem. Se não tiver certeza, pergunte a alguém ou saiba mais sobre um comando antes de executá-lo.

Josh
fonte