主页 / server / 问题 / 104577
Accepted
Tom Dunham
Asked: 2010-01-21 05:32:29 +0800 CST

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

  • 772

所以我试图找出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/伪/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）指向同一个地方；我认为它们被重定向到启动脚本中的同一个文件，所以这符合。

但是当我查找索引节点号为 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 Jan 20 13:42 1
     26471 --w------- 0 根根 10485812 Jan 20 13:42 2
   6815772 c--------- 1 根系统 13，2009 年 6 月 7 日 12 日 3
# 文件 0 1 2 3
0：特殊字符（13/2）
1：ASCII文本
2：ASCII文本
3：字符特殊（13/12）

（我可以跟踪其中一个 fd 并从中找出它是哪个文件。我问是因为我显然不了解 fd 和 inode 之间的关系足够深入）。

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

solaris inode process

1 个回答

  1. Best Answer

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

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

    编辑：

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

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

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

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

    日志文件不太可能成为这种“隐藏的自动删除”文件的候选者；但不小心做到这一点并不难。

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

    编辑：

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

    • 6

相关问题