昨天我遇到了一个问题，一台服务器 (S1) 丢失了连接。从那台服务器，有一个与 NFS 共享的目录到另一台服务器 (S2)，没有主目录，也不在 $PATH 中，但有一个用于存储旧文件以供存档的目录。S1 在几个小时后恢复在线，但现在我无法访问 S2，因为这个原因（我确信这是因为这个，因为所有其他服务都在正常运行）。ssh 连接在这里挂起：debug1：进入交互式会话。我知道重新启动可以完成这项工作，但考虑到这是一个大型应用程序的 NAS，如果我这样做，我的老板会杀了我。还有其他方法可以解决这个问题吗？我尝试使用不同的用户，但它们都挂在同一个地方。我连接到 HP iLO，但甚至在那里我都无法使用我的用户名。
提前致谢。
答案1
（您不会碰巧在 S2 上有自动安装的目录，是吗？）
尝试使用没有交互式会话的 ssh：
$ ssh -tvv you@S2 /usr/bin/env MAILCHECK=0 MAIL=/dev/null MAILPATH=/dev/null sh
“-vv” 让 ssh 打印额外的输出——不会造成任何影响——而“-t” 则告诉它分配一个 TTY，即使它正在运行命令而不是启动交互式 shell。命令 env 将一堆 MAIL* 环境变量设置为空，如果您有 mail-on-NFS，这些变量很有用，然后，最后启动一个简单的 shell。
或者，如果合适的话，尝试HOME=/ /bin/su -代替sh。
如果您确实进入了，一定要尝试卸载 NFS 挂载。如果失败（很可能），请尝试使用-f。如果失败（仍然很可能），Linux 可以-l选择执行延迟卸载：它将从文件系统树中分离挂载点，这应该会使任何新进程响应。但是，任何现有进程仍将挂起，除了重新启动之外没有其他办法。
答案2
如果我读了你的消息报告：一个用户正在尝试通过 ssh 连接到 user@S2 S2 从 S1 挂载文件系统 S1 之前出现问题，导致 S2 上发生 NFS 错误。挂载在 S2 上的文件系统不是主目录。
您使用的是自动挂载程序吗？这是 Linux 还是其他版本的 UNIX？
如果丢失的 NFS 挂载是主目录或在用户登录过程中以某种方式访问，则此类问题很有意义 - 登录过程尝试访问该目录并陷入磁盘等待。由于身份验证成功，因此它几乎一定是这些问题之一。
所以你 1000% 确定用户的主目录不是 NFS？如果不是，你应该能够通过以 root 身份登录系统并检查他们与有问题的 NFS 文件系统交互的任何实例来读取 S2 上的用户点文件
您应该能够通过以 root 身份登录系统（如果没有其他操作，则通过 iLO 控制台）并执行以下命令进行验证：ps auxww | grep D
您可以以 root 身份登录系统，对吗？还是有什么我不明白的地方？
强制卸载，然后重新启动 S2 上的 NFS 进程，然后重新安装应该可以解决这个问题，尽管您可能会遇到一堆卡住的进程，直到重新启动才会消失。