Re: Getting PIDs out of inodes?

["Ismael Farfán" <sulfurfff@gmail.com>]

2014/1/15 Al Viro :
> On Wed, Jan 15, 2014 at 04:08:01PM -0600, Ismael Farf??n wrote:
>>
>> I'd like to know who created or inherited (as in fork) them. I mustn't
>> talk ill of the dead, but they are my prime suspects because of this
>> (doesn't shows with ps):
>> [49886.362859] umount.nfs[8425]: segfault at 19... bla bla
>>
>> Given what I read[1,2], there doesn't seem to be a direct way to get
>> the struct file (which contains a PID) out of the inode.
>
> That makes no sense.  struct file does *not* contain a PID.
>

This comment in struct file fooled me then :/
int f_owner; /* pid or -pgrp where SIGIO should be sent */

>> I don't know if it's possible to script an iteration with crash over
>> all tasks in search of a particular inode.
>>      DENTRY           INODE       TYPE PATH
>> ffff880936419900 ffff8808d17c5518 REG  foo.txt
>>
>> Any ideas on how to know who created the file descriptors?
>
> ... and descriptor != struct file.  Moreover, if "who?" is "which process?",
> it might have been dead, buried and its PID reused a long time ago - opened
> file can easily outlive the process that had opened it.  What are you actually
> trying to do?  Details, please...

I have some inodes open such that they don't show with fuser...

crash> fuser /mnt
No users of /mnt
crash> mount -f /dev/sdb1
VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME
ffff88094c4cc680 ffff880946018c00 myfs /dev/sdb1 /mnt
OPEN FILES
DENTRY INODE TYPE PATH
ffff880936419900 ffff8808d17c5518 REG foo1.txt
ffff8809270079c0 ffff880927150618 REG foo2.txt
<< and another 26 of them! >>

Because of those guys I can't umount the FS (hence there's a bug!)

I'm trying to figure out what command, daemon, *kernel thread*, PID,
unicorn... created or left them there.

Even if the PID was reused (unlikely because the system ran only 18
hours) I can try to match it in other logs. For instance, my prime
suspect is NFS, but I *can't* blame it only with this as proof (from
dmesg) :
[45249.452255] umount.nfs[30037]: segfault at 19 ip ...


I'm trying to solve it and learn crash at the same time :)

Cheers


-- 
Do not let me induce you to satisfy my curiosity, from an expectation,
that I shall gratify yours. What I may judge proper to conceal, does
not concern myself alone.