所以我试图找出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 编号的文件。谁能给我一个关于这可能是什么的想法（或者甚至让我知道我的推理到目前为止是否完全被打破）？
