Por que o meu OS X Terminal exibe uma janela em branco em vez de um prompt de comando após a instalação do MySQL?

1

Após instalar o MySQL 5.1.50 de 64 bits e executar o pacote que configura o MyQL para ser executado na inicialização, o aplicativo Terminal agora exibe esporadicamente uma janela em branco, assim:

texto alternativo

Consegui recuperar o prompt de comando depois de seguir as instruções da coluna MacFixIt na CNET: O OS X Terminal exibe uma janela em branco em vez de um prompt de comando

No entanto, o Terminal ficará intermitentemente em branco e eu tenho que repetir o processo novamente e isso está me deixando louco. O artigo da CNET cura os sintomas, mas a causa desse problema ainda é desconhecida. Alguém tem alguma teoria ou experiência para compartilhar, a fim de resolver esse problema irritante permanentemente?

macos troubleshooting terminal

— GeneQ
fonte

Você resolveu este problema?

— JasKerr 1/10/10

Isso aconteceu mais algumas vezes. Cada vez que utilizava o procedimento sugerido pela CNET para corrigi-lo. Então nunca mais aconteceu (até agora). Gostaria de saber o que causou isso. Talvez a Apple silenciosamente faça uma atualização que a corrigiu.

— GeneQ 01/10

Uma fonte comum disso é se você executar sudoe fechar o terminal enquanto o espera pela inserção da senha. Isso trava sudo, o que impede outros logins. Para resolver o problema, use o Activity Monitor (ou outro terminal, se houver um aberto) para interromper o sudoprocesso. (Obviamente, se não houver nenhum sudoprocesso, este não é o problema.)

— Chris Página

A propósito, esse artigo da C | Net está incorreto sobre “… você pode dizer ao terminal para especificar o shell usado e ignorar a necessidade de procurar informações da conta…” Todos os shells e comandos emitidos pelo Terminal são executados via / usr / bin / Conecte-se. Tudo que a interface do usuário está indicando é que o shell padrão é selecionado por / usr / bin / login (ele analisa as informações da sua conta de usuário), mas se você personalizar o shell, o Terminal simplesmente informará / usr / bin / login para usar esse shell do padrão. O logon ainda deve procurar informações da conta do usuário para ... logon antes de executar o shell ou outro comando.

— Chris Página

4

Uma causa comum para isso é um processo "sudo" travado. Se você executar o sudo e ele solicitar sua senha, mas você fechar o terminal, o sudo ficará pendurado para sempre aguardando a senha, e isso bloqueia qualquer outro logon até que você a mate.

A solução é eliminar o processo "sudo" com o Activity Monitor.

Acredito que o sudo foi corrigido no Mac OS X Lion 10.7 para sair se você fechar o terminal.

— Chris Page
fonte

Matando todos os javaprocessos tem também resolveu isso, para mim

— Peter Becich

0

Tente executar jobsno Terminal para ver se esse shell possui algum processo filho em segundo plano. Se houver algo super pesado em execução em segundo plano, talvez isso esteja causando a falta de resposta do shell?

— dtlussier
fonte

Está no login do Unix. (Como mostra a barra de título do terminal). Alguns direitos ou coisas relacionadas à autenticação talvez estejam causando o problema.

— GeneQ 27/08/10

É possível investigar o que está sendo executado após o retorno do prompt, mas antes que ele se repita?

— precisa saber é o seguinte

0

Eu só tive exatamente o mesmo problema, embora tenha ocorrido após a instalação do Git (ou pelo menos foi quando notei o problema).

Abri o Activity Monitor e selecionei para mostrar todos os processos. Percebi que rootestava executando vários (> 10) loginprocessos, poucos shprocessos e um sudoprocesso. Eu logindesisti de todos eles, embora alguns processos não parassem - provavelmente os sudomantinham em suspensão. Depois disso, o Terminal funcionou normalmente e os loginprocessos excessivos que não consegui matar foram encerrados.

Eu acho que o truque é procurar por processos relacionados a login e shell que possam travar novos. Provavelmente, no meu caso, matar o sudoteria sido suficiente.

O artigo da CNet que você consultou é bom para um último recurso.

— Jari Keinänen
fonte

0

Iniciar monitor de atividades
Selecione "Todos os processos, hierarquicamente"
Procure seu processo do Terminal
Tente identificar um processo que pode estar "travado" e interferindo no login

Ou:

executado fgem cada janela ativa do shell

No meu caso, de alguma forma, git diff headhavia sido colocado em segundo plano em uma das minhas conchas, gite lessapareceu sob uma concha na qual pensei que havia apenas um processo de bash. Quando eu fiz fgisso corrigiu o problema. Se a maioria das janelas / abas for apenas "login -> bash", será fácil identificá-las.

— Zac Thompson
fonte

0

Na verdade, eu descobri que o problema estava relacionado a um processo de "login" interrompido. Seguindo a sugestão acima, não vi nenhum processo "sudo" na lista do Activity Monitor, mas notei muitos processos de "login" pertencentes ao root. Eu passei e comecei a matá-los, e um deles acionou algo e o prompt voltou para o iTerm para mim. Consegui evitar reiniciar a máquina.

— não Donald Trump
fonte