Date: Tue, 4 Sep 2012 12:10:07 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Sam Varshavchik <mrsam@courier-mta.com> Subject: Re: What happened to my /proc/curproc/file? Message-ID: <201209041210.07555.jhb@freebsd.org> In-Reply-To: <cone.1346757042.638408.23058.1000@monster.email-scan.com> References: <cone.1346723177.448775.23058.1000@monster.email-scan.com> <20120904101429.GV33100@deviant.kiev.zoral.com.ua> <cone.1346757042.638408.23058.1000@monster.email-scan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, September 04, 2012 7:10:42 am Sam Varshavchik wrote: > Konstantin Belousov writes: > > > The procfs links, as well as any other user of vn_fullpath(9) function, > > can only translate a vnode to path if namecache contains useful data. > > As such, the facilities are not guaranteed to success all the time. > > > > In case of rmdir(2), UFS explicitely purges the cache for directory which > > contained direntry of the removed directory. I suspect that you have > > your test program binary located in the same directory which was the parent > > of the removed one. > > Correct. Looks like the same thing applies if I try to use sysctl to get > KERN_PROC_PATHNAME. > > I need some reliable way to get a process's executable file's name, as long > as it's meaningful (the executable file hasn't been removed). There isn't one. What if the file is renamed, or what if it was executed via a symlink that has been removed? What if there are multiple hard links, which one is the "correct" path to return? The namecache bits are a best effort, but if those are purged, the only approach are left with is a brute-force crawl of the filesystem looking for a file whose stat() results match your executable. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209041210.07555.jhb>