Re: What happened to my /proc/curproc/file?

[Sam Varshavchik]

John Baldwin writes:

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

> > 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?

> > your test program binary located in the same directory which was the parent

the equivalent absolute pathname. Works for me.

If the file is renamed, shouldn't its new name be known? If I give the file's supposed new name to realpath(3), its man page says I'll get back And, I thought that the resolved pathname, in any case, would be the one after all the symlink resolution takes place, like /proc shows on Linux: if, say, I have /usr/local symlinked to /mnt/local-mnt, exec("/usr/local/bin/furgle") gives me a process that, according to /proc, is /mnt/local-mnt/bin/furgle.

What if there are multiple hard links, which

one is the "correct" path to return?

I would say whichever one of them was used to exec() the process. But either one would be ok, I suppose.

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.

Well, for logging purposes, after I get a client process's credentials passed through a domain socket, I was hoping to use the credentials' pid to log the process's executable name. At least that's the code that I'm porting is doing; but this is going to throw a big monkey wrench into the whole thing. Is the dev+ino of what was exec()ed known, for another process? I might be able to get the client voluntarily submit its argv[0], then independently have the server validate it by stat()ing that, and comparing the result against what the kernel says the process's inode is.

pgpd8Y9zf7Zn8.pgp
Description: PGP signature