进程打开了不在任何文件系统上的 inode？

Question

所以我试图找出stderr进程的 的 是否已被重定向到某种异常（它是一个 java 进程，我想要一个线程转储，但它是通过一组启动脚本启动的）。

我找到了我的过程pgrep，并用它pfiles来查看那里有什么：

4366：/foo/bar/platform/solaris2/jre_1.5.0/bin/java -Xmx2048m -Xms10
当前 rlimit：65536 个文件描述符
 0: S_IFCHR 模式:0666 dev:302,0 ino:6815752 uid:0 gid:3 rdev:13,2
    O_RDONLY|O_LARGEFILE
    /devices/pseudo/mm@0:null
 1: S_IFREG 模式:0640 dev:85,56 ino:26471 uid:0 gid:0 size:10485812
    O_WRONLY|O_LARGEFILE
 2: S_IFREG 模式:0640 dev:85,56 ino:26471 uid:0 gid:0 size:10485812
    O_WRONLY|O_LARGEFILE
 3: S_IFCHR 模式:0666 dev:302,0 ino:6815772 uid:0 gid:3 rdev:13,12

所以我可以看到stdout和stderr（文件描述符 1 和 2）指向同一个地方；我认为它们被重定向到启动脚本中的同一个文件，所以这符合。

但是当我查找 inode 编号为 26471 的文件时，我看到了：

# 查找/-inum 26471
/usr/share/man/man3mlib/mlib_MatrixScale_S16_U8_Sat.3mlib
/proc/4366/fd/1
/proc/4366/fd/2
/proc/4366/fd/83

第一个命中是（我确定）不同文件系统上的文件。中的三个条目/proc是我的进程已打开的 fds。

往里看/proc/4366，我看不到比我从pfiles.

# ls -li 0 1 2 3
   6815752 c--------- 1 根系统 13，20 年 1 月 2 日 14:10 0
     26471 --w------- 0 根根 10485812 1 月 20 日 13:42 1
     26471 --w------- 0 根根 10485812 1 月 20 日 13:42 2
   6815772 c--------- 1 根系统 13，2009 年 6 月 7 日 3
# 文件 0 1 2 3
0：字符特殊（13/2）
1：ASCII文本
2：ASCII文本
3：字符特殊（13/12）

（我可以跟踪这些 fds 中的一个并找出它来自哪个文件。我问是因为我显然没有足够深入地理解 fds 和 inode 之间的关系）。

因此，我的进程正在写入某些内容（在某些设备上，使用 inode 26471），然后数据将进入具有不同 inode 编号的文件。任何人都可以让我知道这可能是什么（或者甚至让我知道到目前为止我的推理是否完全被打破）？

Answer 1

AFAIK，find搜索文件系统的目录。如果该文件被删除但仍然存在，因为它是打开的（unix 上的一个常见技巧），它不会被find.

我还没有在 Solaris 中尝试过，但这里有一条关于lsof用于识别此类“已删除但打开”的文件并通过cat /proc/<procid>/fd/<fdid> > /tmp/xxxx

编辑：

似乎您已经确定是这种情况，但仍然想知道这怎么可能。这是一个简短的解释：

在 POSIX 文件系统上，文件由它的 处理inode，目录只不过是一个“路径 => inode”映射。您可以有多个路径“指向”同一个 inode（称为硬链接），并且 inode 会记录它有多少个链接。该rm命令只是调用unlink()此路径，这会减少链接数并“可能”删除文件本身。

但是目录树上的路径并不是对 inode 的唯一可能引用，fd正在运行的进程上的打开也很重要，并且“已删除”的文件在它变为 0 之前不会被真正删除。

正如我在上面提到的，这是一个常见的技巧：如果您有一个临时文件，在您的进程完成运行后不想保留，只需打开它并立即“删除”它。打开的句柄将可靠地工作，当您的进程完成（正常、终止或崩溃）时，系统将删除句柄并干净地删除临时文件。

日志文件不太可能是这种“隐藏的自动删除”文件的候选对象；但不小心做起来并不难。

由于您删除的日志文件仍然存在并正在收集数据，因此简单地复制内容似乎无济于事。所以尝试创建一个到 /proc//fd/ 文件的新硬链接，比如ln /proc/4366/fd/1 /tmp/xxxx. 请注意，没有-s标志，因此ln应该创建一个与原始 inode 具有相同 inode 的新硬链接，而不是符号链接（它只不过是指向现有路径的指针，而不是您想要的）。

编辑：

该ln /proc/... /tmp/...命令无法工作，因为 /proc 和 /tmp 位于不同的文件系统中。不幸的是，我不知道有什么方法可以为现有的 inode 创建路径名。人们希望link()系统调用采用 inode 编号和路径，但它采用源路径和目标路径。