С сегодняшнего дня что-то не так с сервером. На стороне сервера я вижу сообщения в 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-бит:
>> 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 на сервере, вызывая проблемы на всех остальных машинах. Я перезагрузил всю сеть, оставив одну машину выключенной, и никаких проблем не возникло. На самом деле это не исправление, но с тех пор я снова понизил версию этой машины, и все, похоже, стабильно.
Вот пара предложений:
Однажды мне удалось сломать интерфейс loopback (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
У меня была та же проблема, и это решило ее ... но всего на один месяц. Пока не знаю почему. Сегодня мне снова пришлось удалить файлы.
В моем случае это сработало:
https://lists.debian.org/debian-user/2004/10/msg00932.html
Просто отредактируйте скрипт /etc/init.d/halt, в конце должна быть строка
остановка -d -f -i $ poweroff $ hddown
Параметр "-i" отключает все сетевые интерфейсы, но это> кажется слишком рано для бездисковых клиентов, просто попробуйте удалить этот параметр, поэтому
остановка -d -f $ poweroff $ hddown
Обратите внимание, что моя проблема была с NFS на клиенте с диском.
У меня была такая же проблема на сервере nfs debian squeeze, и, похоже, она была вызвана и некоторыми новыми клиентами (Fedora 20). Понижение версии клиентов не было для меня вариантом, после некоторой долгой, болезненной и безуспешной отладки я в конечном итоге обнаружил (другую и, вероятно, несвязанную) ошибку цикла readdir в файловой системе ext4, экспортированной nfs, с большим количеством файлов, похожих на: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1240143
(Я мог ошибаться, насколько я понял, это было исправлено в последних ядрах, поэтому это может повлиять на сжатие debian)
Короче говоря, чтобы избавиться хотя бы от ЭТОЙ ошибки, я обновил свой сервер nfs до debian wheezy (установив версию nfs на 3), и теперь (с той же файловой системой и теми же клиентами) прошла неделя без сообщения «не могу отслеживать» / проблема "не отвечает" (до обновления это было повседневное дело)