Re: Getting PIDs out of inodes?

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Jan 16, 2014 at 10:14:42AM -0600, Ismael Farfán wrote:
> 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 :)

Best is probably to report the details (with kernel versions, etc.) to
linux-nfs@vger.kernel.org.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html