Cliente NFS incapaz de montar compartilhamentos de servidores que, de outro modo, seriam responsivos

2

Não conseguimos montar os compartilhamentos NFS em nosso cliente Debian Lenny Database / Web-App NFS de nosso servidor NFS do Fedora 8. Comando de montagem manual com opções e montagem assistida usando opções fstab retorna o mesmo comportamento. Máquina falhou inesperadamente 6 dias atrás, mas este problema parece ter surgido 3 dias atrás. (E sim, acabei de me informar esta manhã pela equipe responsável por isso)

Este mesmo servidor está funcionando corretamente para todos os outros clientes NFS. O cliente NFS também armazena alguns de seus compartilhamentos de volta para outros clientes e para o servidor NFS, que também está funcionando corretamente.

Os processos dependem da suspensão desses suportes desde o dia 26. O Cron foi desativado para manter a média de carga em um nível apropriado.

As montagens estão sendo autenticadas corretamente no servidor NFS com base nas mensagens de 'solicitação de montagem autenticada' no servidor, mas o cliente é

# mount -vvv -t nfs server.example.org:/shared/foo /shared/foo/
mount: fstab path: "/etc/fstab"
mount: lock path:  "/etc/mtab~"
mount: temp path:  "/etc/mtab.tmp"
mount: spec:  "server.example.org:/shared/foo"
mount: node:  "/shared/foo/"
mount: types: "nfs"
mount: opts:  "(null)"
mount: external mount: argv[0] = "/sbin/mount.nfs"
mount: external mount: argv[1] = "server.example.org:/shared/foo"
mount: external mount: argv[2] = "/shared/foo/"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] = "rw"
mount.nfs: trying 192.168.xxx.xxx prog 100003 vers 3 prot TCP port 2049
mount.nfs: trying 192.168.xxx.xxx prog 100005 vers 3 prot UDP port 51852

E lá fica indefinidamente sem mais saída na tela. Muito provavelmente devido ao problema indicado pelo seguinte:

Mar 28 10:17:14 db kernel: [1299206.229436] mount.nfs     D e250c5d5     0 20597  20596
Mar 28 10:17:14 db kernel: [1299206.229439]        c0a3cde0 00000086 f7555b00 e250c5d5 0001ca16 c0a3cf6c ce0a9020 0000000d 
Mar 28 10:17:14 db kernel: [1299206.229444]        0013bc68 077ffe57 00000003 00000000 00000000 00000000 00000000 00000246 
Mar 28 10:17:14 db kernel: [1299206.229447]        c0a77c90 00000000 c0a77c98 ce000a7c f8e047c1 c02c93a4 f8e0479c f4518588 
Mar 28 10:17:14 db kernel: [1299206.229451] Call Trace:
Mar 28 10:17:14 db kernel: [1299206.229465]  [<f8e047c1>] rpc_wait_bit_killable+0x25/0x2a [sunrpc]
Mar 28 10:17:14 db kernel: [1299206.229485]  [<c02c93a4>] __wait_on_bit+0x33/0x58
Mar 28 10:17:14 db kernel: [1299206.229490]  [<f8e0479c>] rpc_wait_bit_killable+0x0/0x2a [sunrpc]
Mar 28 10:17:14 db kernel: [1299206.229505]  [<f8e0479c>] rpc_wait_bit_killable+0x0/0x2a [sunrpc]
Mar 28 10:17:14 db kernel: [1299206.229519]  [<c02c9428>] out_of_line_wait_on_bit+0x5f/0x67
Mar 28 10:17:14 db kernel: [1299206.229523]  [<c0138859>] wake_bit_function+0x0/0x3c
Mar 28 10:17:14 db kernel: [1299206.229528]  [<f8e04c06>] __rpc_execute+0xbe/0x1d9 [sunrpc]
Mar 28 10:17:14 db kernel: [1299206.229543]  [<f8dffa72>] rpc_run_task+0x40/0x45 [sunrpc]
Mar 28 10:17:14 db kernel: [1299206.229557]  [<f8dffb00>] rpc_call_sync+0x38/0x52 [sunrpc]
Mar 28 10:17:14 db kernel: [1299206.229573]  [<f8e80351>] nfs3_rpc_wrapper+0x14/0x49 [nfs]
Mar 28 10:17:14 db kernel: [1299206.229591]  [<f8e8044f>] do_proc_fsinfo+0x54/0x75 [nfs]
Mar 28 10:17:14 db kernel: [1299206.229607]  [<f8e80481>] nfs3_proc_fsinfo+0x11/0x36 [nfs]
Mar 28 10:17:14 db kernel: [1299206.229621]  [<f8e70514>] nfs_probe_fsinfo+0x78/0x47f [nfs]
Mar 28 10:17:14 db kernel: [1299206.229634]  [<f8dffd1f>] rpc_shutdown_client+0x9d/0xa5 [sunrpc]
Mar 28 10:17:14 db kernel: [1299206.229647]  [<f8dffb58>] rpc_ping+0x3e/0x47 [sunrpc]
Mar 28 10:17:14 db kernel: [1299206.229662]  [<f8e00845>] rpc_bind_new_program+0x69/0x6f [sunrpc]
Mar 28 10:17:14 db kernel: [1299206.229677]  [<f8e71584>] nfs_create_server+0x37b/0x4fa [nfs]
Mar 28 10:17:14 db kernel: [1299206.229693]  [<c01621c1>] __alloc_pages_internal+0xb5/0x34e
Mar 28 10:17:14 db kernel: [1299206.229700]  [<c013882c>] autoremove_wake_function+0x0/0x2d
Mar 28 10:17:14 db kernel: [1299206.229703]  [<c01e7e3c>] idr_get_empty_slot+0x11c/0x1ed
Mar 28 10:17:14 db kernel: [1299206.229711]  [<f8e78fbd>] nfs_get_sb+0x528/0x810 [nfs]
Mar 28 10:17:14 db kernel: [1299206.229724]  [<c01e8125>] idr_pre_get+0x21/0x2f
Mar 28 10:17:14 db kernel: [1299206.229729]  [<c0180159>] vfs_kern_mount+0x7b/0xed
Mar 28 10:17:14 db kernel: [1299206.229734]  [<c0180209>] do_kern_mount+0x2f/0xb8
Mar 28 10:17:14 db kernel: [1299206.229738]  [<c019264a>] do_new_mount+0x55/0x89
Mar 28 10:17:14 db kernel: [1299206.229743]  [<c0192825>] do_mount+0x1a7/0x1c6
Mar 28 10:17:14 db kernel: [1299206.229747]  [<c02ca52a>] error_code+0x72/0x78
Mar 28 10:17:14 db kernel: [1299206.229752]  [<c0190895>] copy_mount_options+0x90/0x109
Mar 28 10:17:14 db kernel: [1299206.229756]  [<c01928b1>] sys_mount+0x6d/0xa8
Mar 28 10:17:14 db kernel: [1299206.229760]  [<c0108857>] sysenter_past_esp+0x78/0xb1
Mar 28 10:17:14 db kernel: [1299206.229766]  =======================

O funcionamento em rede está funcionando corretamente, pois os usuários de produção no Front End do aplicativo da Web do banco de dados não estão vendo interrupções no serviço nem problemas de desempenho.

A memória está bem:

db:/var/log# free -m
             total       used       free     shared    buffers     cached
Mem:         24352      19426       4926          0        281      18283
-/+ buffers/cache:        860      23492
Swap:         7632          0       7632

/ etc / fstab:

server.example.org:/shared/foo  /foo        nfs defaults    0 0

Linha relevante do / etc / exports do servidor:     / shared / foo 192.168.xxx.xxx (rw, no_root_squash)

O TCPDump parece normal. Eu posso postá-lo se alguém quiser, mas é bastante grande e não parece ter nada claramente desagradável na saída.

    
por Magellan 28.03.2012 / 19:39

1 resposta

1

Eu fiquei sem tempo para solucionar problemas e acabei reiniciando os serviços depois de matar algumas outras tentativas de montagem que os desenvolvedores também tinham disparado.

Reiniciar o portmap e o serviço nfs da Debian fez com que isso funcionasse novamente DEPOIS de matar as tentativas de montagem do cliente. O serviço NFS reiniciou os processos rpc.statd, rpc.idmapd e rpc.mountd.

Os Stacktraces não estavam mais sendo gerados para novas solicitações de montagem depois que as tentativas de montagem antigas foram eliminadas.

    
por 28.03.2012 / 20:37

Tags