Отчаянно: истекло время ожидания, блокировка не может контролировать / демонтировать
С этого дня что-то не так с сервером. На стороне сервера я вижу сообщения в dmesg следующее:
statd: server rpc.statd not responding, timed out
lockd: cannot unmonitor <client>
statd: server rpc.statd not responding, timed out
lockd: cannot monitor <client>
На стороне клиента я вижу в dmesg:
lockd: server <server> not responding, still trying
lockd: server <server> OK
Это парализует всю сеть! Я попробовал это решение, предложенное Сианем, но это не имеет значения.
Сервер, Debian Linux, Squeeze 64-bit:
>> uname -a
Linux <server> 2.6.32-5-amd64 #1 SMP Fri May 10 08:43:19 UTC 2013 x86_64 GNU/Linux
Клиенты Linux Mint 13-64bit:
>> uname -a
Linux <client> 3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Я не запускал обновление на сервере, поэтому я не знаю, что могло измениться. Я обновил одну из наших клиентских машин, но не могу понять, почему это будет мешать работе сервера, так как все машины кажутся затронутыми. Любые идеи о том, как это исправить?
ОБНОВЛЕНИЕ 1
Сервер останавливается на некоторое время на
Starting portmap deamon
Starting NFS common utilities: statd idmapd
Это занимает около 2 минут, пока загрузка продолжается...
ОБНОВЛЕНИЕ 2
Это действительно клиентская машина, которая была обновлена, что вызвало это. Кажется, это как-то застопорилось statd на сервере, вызывая проблемы на всех других машинах. Я перезагрузил всю сеть, оставив эту машину выключенной, и у меня не возникло никаких проблем. Не совсем исправление, но с тех пор я снова снизил версию этой машины, и все кажется стабильным.
4 ответа
Вот пара предложений:
Мне когда-то удалось сломать петлевой интерфейс (lo) и благодаря этому несколько сервисов, таких как NFS, перестали работать должным образом. Смотри с ifconfig если у тебя все еще есть любимый lo интерфейс работает и работает. Если это не так, иди посмотреть /etc/network/interfaces и посмотрим, что происходит.
Также, как уже упоминали некоторые люди, проверьте команды pgrep -v statd а также netstat -tlnpu чтобы увидеть, работает ли statd.
Или, возможно, кто-то что-то изменил под /etc на стороне сервера? Если у вас нет /etc под управлением версиями посмотрите, были ли какие-либо файлы недавно изменены: find /etc -mtime -14 покажет файлы, измененные за последние 14 дней, например.
Посмотрите здесь: http://sophiedogg.com/lockd-and-statd-nfs-errors/
Пытаться:
# /etc/init.d/nfs-common stop
# /etc/init.d/nfs-kernel-server stop
# rm -rf /var/lib/nfs/statd/sm/*
# rm -rf /var/lib/nfs/statd/sm.bak/*
# /etc/init.d/nfs-common start
# /etc/init.d/nfs-kernel-server start
У меня была та же проблема, и это решило ее... но только на один месяц. Я не знаю почему сейчас. Мне пришлось удалить файлы снова сегодня.
У меня была такая же проблема на сервере сжатых файлов Debian nfs, и она, похоже, была вызвана некоторыми новыми клиентами (Fedora 20). Понижение клиентов не было для меня вариантом, после некоторой долгой, мучительной и неудачной отладки я обнаружил (различную и, вероятно, не связанную) ошибку цикла readdir в экспортированной файловой системе ext4 nfs с большим количеством файлов в ней, например: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1240143
(Я могу ошибаться, из того небольшого, что я понял, это было исправлено в последних ядрах, поэтому может повлиять на сжатие Debian)
Короче говоря, чтобы избавиться хотя бы от этой ошибки, я обновил свой сервер nfs до debian wheezy (принудительно установив версию nfs до 3), и теперь (с той же файловой системой и теми же клиентами) прошла неделя без "не может контролировать"/"не отвечает" проблема (до обновления это было повседневным делом)
Это сработало для моего случая:
https://lists.debian.org/debian-user/2004/10/msg00932.html
Просто отредактируйте скрипт /etc/init.d/halt, в конце должна быть строка
halt -d -f -i $poweroff $hddown
Параметр "-i" отключает все сетевые интерфейсы, но это> слишком рано для бездисковых клиентов, просто попробуйте удалить этот параметр, поэтому
halt -d -f $poweroff $hddown
Обратите внимание, что моя проблема была с NFS на клиенте с диском.