Em um dos sites de meus clientes, o funcionário local desligou o servidor Solaris 10 x86 local, puxou as entradas de energia, moveu-o e agora ele não inicia corretamente. Ele inicializa e apresenta um prompt que permite fazer login. Este parece ser um marco de usuário único (ou equivalente).
Indo mais fundo, acho que o SMF não está permitindo que o sistema se torne multiusuário. O SMF estava gerando uma tonelada de erros no autofs, depois de algumas brincadeiras com ele, consegui gerar erros no inetd e no nfs/client. Tudo isso me diz que o problema está em algum arquivo ou banco de dados de estado SMF que precisa ser corrigido/excluído/recriado ou algo assim, mas não sei qual é o problema real.
Por “gerar erros”, quero dizer que a cada segundo recebo uma mensagem no console dizendo “Tempo limite de saída do método ou serviço esgotado. Contrato matador <#>.” Isso dificulta a interação com o computador.
A execução de svcs –xv mostra o serviço como “ativado”, no estado “desativado”, motivo “O método inicial está em execução”. Brincar com o svcadm no serviço não faz nada, exceto confirmar que o serviço não está em estado de manutenção.
Os logs em /lib/svc/log/$SERVICE apenas informam que esse loop está acontecendo uma vez por segundo. Os logs em /etc/svc/volatile/$SERVICE confirmam que na inicialização o serviço é tentado iniciar e imediatamente interrompido, sem mais entradas. Observe que o log do sistema não está iniciando porque o log do sistema depende do autofs, portanto não tenho syslog ou dmesg.
Pesquisando todos esses termos no Google acaba me dizendo como depurar/consertar autofs ou nfs/client ou inetd ou rpc/gss (que era a dependência que o SMF estava usando como desculpa para evitar que o nfs/client “iniciasse”, afirmava que rpc/gss estava “indefinido”, o que é incorreto, já que tudo isso costumava funcionar. Eu o reativei com o inetadm, mas o inetd ainda não inicia corretamente). Mas penso que o problema é o SMF em geral, e não os serviços individuais.
Fazer um restore_repository para o “manifest_import” não faz nada para melhorar, ou mesmo alterar de forma detectável, a situação. Não usei um backup de inicialização porque as últimas inicializações não foram úteis.
Eu disse ao cliente que, como os diretórios de dados valiosos estão em um sistema de arquivos separado (que o fsck é limpo e intacto), poderíamos simplesmente reinstalar o solaris 10 na partição /. Mas isso parece uma solução muito parecida com o Windows para infligir esse problema.
Então. Alguma idéia de qual peça está quebrada e como posso consertá-la?
Atualização 1: Devo provavelmente mencionar que este sistema possui dois sistemas de arquivos, / e /export. Ambos fsck limpam e montam corretamente.
Responder1
Uma causa raiz comum desse problema é um problema durante a montagem de sistemas de arquivos devido a alguma corrupção do sistema de arquivos. Isso está se tornando bastante raro, especialmente para os locais, mas seu cliente não colocou as probabilidades a seu favor ao desabilitar o registro do ufs (que evita a maioria das corrupções do sistema de arquivos causadas por um desligamento repentino) e ao não usar o ZFS (que não pode ser corrompido em primeiro lugar por design).
Você pode ativar a inicialização detalhada do smf editando /boot/grub/menu.lst. A maneira precisa depende da versão e atualização do Solaris, mas geralmente isso é feito substituindo console=graphicspor console=text -v -m verbosena linha que carrega o kernel.
Se você quiser iniciar no modo de usuário único, use console=text -v -m verbose,milestone=single-user.
Para ativar o modo de depuração smf, useconsole=text -v -m debug
Observe que você pode usar o modo de edição do grub para definir temporariamente essas opções.