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