Lockd зависает один или несколько раз в день

0

Сервер работает более 1,5 лет, без проблем. На прошлой неделе начались ошибки и зависание рабочих станций: lockd: не может отслеживать statd: сервер rpc.statd не отвечает, время ожидания истекло

Сервер: ОС: Ubuntu 10.04.4 Ядро: Linux 2.6.32-51-сервер nfs-common 1: 1.2.0-4ubuntu4.2 nfs-kernel-server 1: 1.2.0-4ubuntu4.2 / home xxx0 / 255.255. 0.0 (rw, no_root_squash, небезопасный, асинхронный, wdelay, no_subtree_check) / public xxx0 / 255.255.0.0 (rw, no_root_squash, небезопасный, асинхронный, wdelay, no_subtree_check)

Рабочие станции: Ubuntu 10.04.x ​​сервер: / home / home nfs по умолчанию 0 0 сервер: / public / mnt / public nfs по умолчанию 0 0

Запуск rpcinfo -p как с рабочих станций, так и с серверов возвращает нормально.

Пока lockd заблокирован, сервер доступен на 100%, т. Е. Ssh top df возвращает все как положено. Однако рабочие станции не могут перемещаться между рабочими столами и перестают отвечать, Chrome перестает работать

На сервере ps -aux | grep lockd показывает, что процесс lockd - это D. Однако через пару минут lockd возвращается к S и R, и рабочие станции снова функционируют

После включения nlm_debug я вижу, что процесс lockd действительно зависает

Я заметил в журнале ниже, что lockd застревает на минуту 02:03:21 - 02:04:21

Это повторяется, когда блокировка lockd застревает, и я обнаружил, что после перезагрузки «нарушающей работу» рабочей станции все системы возвращаются к нормальной работе.

Oct  2 02:04:21 fs1 kernel: [647001.312596] lockd: request from 172.x.x.x, port=960
Oct  2 02:04:21 fs1 kernel: [647001.312603] lockd: LOCK          called
Oct  2 02:03:21 fs1 kernel: [646941.418685] lockd: nlmsvc_lookup_host(host='roi-lnx', vers=4, proto=tcp)
Oct  2 02:03:21 fs1 kernel: [646941.418687] lockd: get host roi-lnx
Oct  2 02:03:21 fs1 kernel: [646941.418688] lockd: nlm_lookup_host found host roi-lnx (172.16.16.76)
Oct  2 02:03:21 fs1 kernel: [646941.418689] lockd: nsm_monitor(roi-lnx)
Oct  2 02:04:21 fs1 kernel: [647001.312552] statd: server rpc.statd not responding, 
timed out
Oct  2 02:04:21 fs1 kernel: [647001.312565] lockd: NSM upcall RPC failed, status=-5
Oct  2 02:04:21 fs1 kernel: [647001.312570] lockd: cannot monitor roi-lnx
Oct  2 02:04:21 fs1 kernel: [647001.312572] lockd: release host roi-lnx

Это похоже на ошибку в lockd.

Я провел дни, просматривая Google, и есть пара подобных случаев, но никаких исправлений.

Пожалуйста, дайте мне знать, если у вас есть предложения по решению этой проблемы.

Спасибо Лоуренс

user197989
источник

Ответы:

1

В аналогичной среде с 10.04.4 ubuntu nfs-server обслуживает ок. 50 клиентов Ubuntu / Mac OS X (в основном 12.04.3), у меня была такая же проблема. Клиенты работали только при монтировании домашних каталогов с опцией nolock (чего не следует делать).

После отладки всех возможных вещей в сети в течение двух недель после обнаружения ошибки на сервере стало понятно , что единственным изменением было включение двух новых клиентов (12.04.3) с работающим ядром 3.8.0-29-generic. После удаления этих двух из сети (фактически вчера) statd и lockd снова стабильны на сервере.

Я сообщу о том, что происходит сегодня, когда все клиенты снова будут работать в полную силу.

Есть ли новый клиент в вашей сети?

marz_cyclone
источник
Понижение ядра до 3.2.0-54 действительно решило проблему.
marz_cyclone
Обновление с 3.13.0-40-generic до .13.0-43-generic также решает эту проблему для меня.
Ченминг Чжан
0

У меня также был подобный опыт в cluser с 4 узлами, где все узлы используют 3.2.0-38-generic в Ubuntu 12.04.5. Версия NFS:

dpkg -la | grep nfs
ii  libnfsidmap2                       0.25-1ubuntu2               NFS idmapping     library
ii  nfs-common                         1:1.2.5-3ubuntu3.2                                  NFS support files common to client and server
ii  nfs-kernel-server                  1:1.2.5-3ubuntu3.2                                  support for NFS kernel server

Выясняется, что один из проблемных узлов постоянно «атакует NFS-сервер». После того, как проблемный узел был удален из системы, больше не происходит зависаний.

Ченмин Чжан
источник