Как отмонтировать nfs-шару, если -l, -f не помогают?

А хост с шарой вернуть не пробовал, или там уже всё?

Оставь надежду всяк сюда входящий.

Хост с шарой и так работает нормально. Просто он был перезагружен, из-за этого nfs-шара отвалилась.

Назначить ip-адрес nfs-сервера на какой-нибудь интерфейс клиента, чтобы он сразу получал отлуп (при условии, что клиенте нет NFS-сервера).

Не могу, это приведёт к катастрофе. Тут инфраструктура огромная. Я не могу менять ip-адреса просто так.

Если соединение повисло, оно уже ни на что не реагирует. Никакие kill не помогут. Причем непонятно, почему nfs не всегда так подвисает при отвале связи. Только перезагрузка, только хардкор !

Ребутать крайне нежелательно

А скорее всего придётся. Причём ещё и так

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Но я рад буду ошибиться и узнать, что есть менее хардкорный способ, т.к. пару раз сам такое встречал, правда там, где перезагрузка была допустима (зависал rsync при записи на nfs шару в аналогичной ситуации, шару было также не отмонтировать, rsync не прибить, обычный reboot не работал).

На NFS-сервере адрес то остаётся, клиент на некоторое время потеряет с ним связь. Если клиент и сервер в разных подсетях, то проблем из-за arp не возникнет.

Это вам самому решать какую катострофу устраивать. Посмотрите с помощью tcpdump, пытается ли NFS-клиент что-то слать на NFS-сервер. Лучше всего записать все пакеты в файл и потом их посмотреть при попытке umount.

Если пакеты есть, то можно пробовать назначить ip-адрес клиенту. Насколько мне известно это единственный способ вызвать ошибку записи в сокет — локальный адрес, порт на котором никто не слушает.

Понятно, что желательно сначала воспроизвести ситуацию на тестовых машинах.

А что мешает монтировать nfs с опциями timeo, retrans и retry? Дефолтные значения там оооочень большие.

Запросили ребут, больше выходов не видим. Может быть дадут разрешение на ребут в понедельник\вторник или в среду.

Всем спасибо. Выхода нет. Всё тлен.

Это довольо критично, так как не отрабатываются утилиты типа «df», а от этой утилиты зависят многие скрипты и программы. Например, программа для бекапа вызывает утилиту «df -P» и не может корректно завершиться. Из-за этого возникали проблемы с бекапами на сервере.

А для того чтобы в будущем такого не приключилось, будут изменены параметры монтирования, как vel посоветовал?

а зафильтровать временно коннекты к nfs-серверу не?

iptables -I OUTPUT 1 -p tcp --dport 2049 -j REJECT --reject-with tcp-reset

и попытаться отмонтировать?

Нужно побольше почитать про эти опции, рассказать всей команде Linux, что нужно монтировать именно так.

Не факт, что все захотят слушаться и т.д. Да и серваков слишком много, где-то в fstab всё записано и т.д. Ну я попробую поднять этот вопрос.

А что потом? Попытаться отмонтировать?

P.S. Порт 2049 в данный момент не прослушивается.

nfs-службу пытались останавливать и отмонтировать, не помогает.

Да и серваков слишком много

В смысле nfs клиентов?

Ну я попробую поднять этот вопрос.

Лучше его поднять именно сейчас, когда всё горит: происшедшая авария очевидна, а не теоретична. Это повысит мотивацию. Хотя если отвечать за это должны не они, то не особо поможет, можно только на сострадание надеяться.

У тебя есть tcp-соединение с нфс-сервером? Попытки послать по нему данные или восстановить его должны активно блокироваться (tcp-reset)

Возможно сначала нужно убить на клиенте все что открыло файлы, а потом уже пытаться размонтировать.

fusermount -uz бывает срабатывает тогда, когда umount -lf нет.

хахаха, true that

это ведро чувак. перезагрузи ведро.)))

Не знаю как сейчас, но раньше было, что linux NFS клиент очень плохо себя вёл, когда NFS сервер выключили и включили. Клинет считал, что сервер есть и пытался слать ему запросы, считая что шара уже смонтирована, а сервер так не считал. Опции работали непонятно как, иногда позволяли отмонировать, иногда всё было как у ТС. «Подмена» ip помогала.

umount -f -l /mnt/blah пробовал?

Да.

-f -l вместе? Ещё трюк с айпи. Я давно не мудохался с nfs, но вроде эти способы должны работать

Да, -l и -f вместе.

Способ

unless "umount -l" solves your problem, you can set up a fake server with the same address as the one that has gone away - but you don't actually have to set up a new sever or anything. The easiest way out of the blocking/hung umount situation is to set up a local alias IP interface, as follows:

ifconfig eth0:nfstmp 11.22.33.44 netmask 255.255.255.255
umount -l /mnt/deadnfsmount    # -l or -f or whichever that gets the job done
ifconfig eth0:nfstmp down

(obviously 11.22.33.44 being the (former) IP address of the (now dead) NFS server)

запретили, так как сервер продакшн и все боятся.

Вообще-то если старый nfs-сервер жив, то мудрить с айпи не и нужно, это придумали на случай если сервер пропал и сгинул. Он точно жив, доступен и имеет старый IP?

Да, он доступен и 100% работает.