“Último recurso” Linux comando de terminal para reiniciar (por ssh) em caso de um bug do kernel?

Question

Eu tenho um pequeno servidor com o Ubuntu 10.04; Eu estou manipulando este servidor de outro computador via ssh , e eu tentei usar nfs nele para compartilhar arquivos. Isso funciona principalmente, até que um dos clientes desmonta e eu quero desligar nfs-kernel-server no servidor. Enquanto a parada parece adequada:

$ sudo service nfs-kernel-server stop
 * Stopping NFS kernel daemon                                                     [ OK ] 
 * Unexporting directories for NFS kernel daemon...                               [ OK ] 

... Eu obtenho algo assim no log:

Feb  5 11:50:17 user init: statd main process (3806) killed by KILL signal
Feb  5 11:50:17 user init: statd main process ended, respawning
Feb  5 11:50:17 user init: idmapd main process (3808) killed by KILL signal
Feb  5 11:50:17 user init: idmapd main process ended, respawning
Feb  5 11:50:17 user statd-pre-start: local-filesystems started
Feb  5 11:50:17 user sm-notify[3815]: Already notifying clients; Exiting!
Feb  5 11:50:17 user rpc.statd[3830]: Version 1.1.6 Starting
Feb  5 11:50:17 user rpc.statd[3830]: Flags: 

... o que significa que alguns processos relacionados ao nfs não se importavam comigo dizendo parar e reaparecer novamente. Se neste momento eu tentar fazer sudo service nfs-kernel-server start (novamente via ssh), esse comando congela, e em /var/log/syslog eu recebo isso:

Feb  5 11:43:55 user mountd[2045]: authenticated mount request from 192.168.0.2:1005 for /media/disk (/media/disk)
Feb  5 11:45:19 user mountd[2045]: Caught signal 15, un-registering and exiting.
Feb  5 11:45:19 user kernel: [27428.148368] nfsd: last server has exited, flushing export cache
Feb  5 11:45:19 user kernel: [27428.148431] BUG: Dentry d0bc8b28{i=1f6,n=} still in use (1) [unmount of vfat sdd8]
Feb  5 11:45:19 user kernel: [27428.148473] ------------[ cut here ]------------
Feb  5 11:45:19 user kernel: [27428.148481] kernel BUG at /build/buildd/linux-2.6.32/fs/dcache.c:670!
Feb  5 11:45:19 user kernel: [27428.148491] invalid opcode: 0000 [#1] SMP 
Feb  5 11:45:19 user kernel: [27428.148501] last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
...
Feb  5 11:45:19 user kernel: [27428.148807] Call Trace:
Feb  5 11:45:19 user kernel: [27428.148824]  [<c024c780>] ? vfs_quota_off+0x0/0x20
Feb  5 11:45:19 user kernel: [27428.148838]  [<c021d4fc>] ? shrink_dcache_for_umount+0x3c/0x50
Feb  5 11:45:19 user kernel: [27428.148852]  [<c020d090>] ? generic_shutdown_super+0x20/0xe0
...
Feb  5 11:45:19 user kernel: [27428.149511] EIP: [<c021d4a9>] shrink_dcache_for_umount_subtree+0x249/0x260 SS:ESP 0068:ccc6de6c
Feb  5 11:45:19 user kernel: [27428.149631] ---[ end trace 6198103bb62887ac ]---
Feb  5 11:49:53 user init: idmapd main process (838) killed by TERM signal
Feb  5 11:49:53 user init: idmapd main process ended, respawning
Feb  5 11:49:53 user rpc.statd[769]: Caught signal 15, un-registering and exiting.
Feb  5 11:49:53 user init: statd main process ended, respawning
Feb  5 11:49:53 user statd-pre-start: local-filesystems started
Feb  5 11:49:53 user sm-notify[3790]: Already notifying clients; Exiting!
Feb  5 11:49:53 user rpc.statd[3806]: Version 1.1.6 Starting
Feb  5 11:49:53 user rpc.statd[3806]: Flags: 
...

Agora, a questão é essa - depois que esse bug acontece, o servidor ssh do servidor é (por algum motivo) normalmente "vivo", para que eu possa fazer login via ssh novamente e tentar fechar processos ( e perceber que é impossível matar /usr/sbin/rpc.nfsd 8 , que é o que está pendurado).

MAS - se neste momento, eu tentar emitir uma reinicialização via sudo shutdown -r now && exit do ssh, então este PC servidor irá iniciar o processo de reinicialização - mas não o completará; ele vai cair para um terminal, despejar algumas mensagens de erro e ficar lá :(

O problema é - o PC do servidor é realmente difícil de acessar, e ter que ir lá para executar o Alt + SysRq + REISUB para reinicializar corretamente (se o kernel reage àquele combo de teclas; caso contrário, é um powerdown difícil) Realmente difícil.

Então, minha pergunta é - existe algum comando "reboot hardcore" no Linux, que vai mais "garantir" que o PC irá reiniciar (e não apenas travar / congelar), mesmo que tenha encontrado um bug no kernel - e qual eu poderia emitir via ssh ? Algo que seria o equivalente a um desligamento strong (ou seja, ligar a energia, por exemplo, segurando o botão de energia por mais de 10 segundos) e powerup rígido?     

Answer 1

Para garantir que o sistema seja reinicializado não importa o que aconteça, sempre faço esta sequência:

# echo s > /proc/sysrq-trigger
# echo u > /proc/sysrq-trigger
# echo s > /proc/sysrq-trigger
# echo b > /proc/sysrq-trigger

Isso solicita que o kernel faça:

• sincronização de emergência dos dispositivos de bloco
• mount readonly de todos os sistemas de arquivos
• novamente uma sincronização
• forçar uma inicialização imediata; você também pode usar o para poweroff.

Ver, por exemplo, aqui para obter explicações sobre esse recurso.

    

Answer 2

Você tem que ignorar o processo de desligamento normal que desmonta os sistemas de arquivos, pára os daemons e assim por diante. É aqui que ele pára - não pode parar os processos com segurança. O que você precisa é de reboot -f ou poweroff -f o que você quiser alcançar (alguns sistemas init podem trazer seus próprios comandos - systemd , por exemplo). O recurso "force" pula os processos de desligamento regulares e vai diretamente para a reinicialização do hardware.