AskBSD: Is there any reliable way to get the path of the running process when procfs is not mounted? reddit / BSD ---------------------------------------------------------------------- almafa · 2010-04-18 16:25 The question surfaces once a while: How to get the full path of the executable running? Linux solves this via the /proc//exe symbolic link. However, on BSD, procfs is often not mounted (and even if it is mounted, such a symbolic link does not always exist). On FreeBSD 6.0 and later, there is sysctl call for that (KERN\_PROC\_PATHNAME); however, I don't know how to solve this on other BSD systems. Some shells set the "_" environment variable, but that's quite unreliable... ---------------------------------------------------------------------- wsgeek · 2010-04-18 19:16 Well, I'm not sure if this requires that procfs be mounted, but you could run the 'top' command and grep for the line that has your PID, and then the path is right there. Then this begs the question, "Well how does 'top' know this information?".... Not sure. You could find the source to 'top' and look at that for the answer if you need a programmatic way to get your information. ---------------------------------------------------------------------- almafa · 2010-04-18 20:02 I don't see the path using 'top'. Is there some specific flag for that? Skimming the man page I don't see anything. This is on OpenBSD 4.3, with procfs mounted. ---------------------------------------------------------------------- [deleted] · 2010-04-19 03:11 [deleted] ---------------------------------------------------------------------- puffybaba · 2010-04-19 04:26 ps -auxww will show you all running processes. For any given process, which $string where $string is the name of the process, will show you the path to the binary. ---------------------------------------------------------------------- harlows_monkeys · 2010-04-19 10:31 Don't you mean "a path" of the running process? There's no such thing as "the path" in Unix, thanks to hard links. ---------------------------------------------------------------------- almafa · 2010-04-19 16:41 'which' shows the path of the executable which would be found first in the $PATH (I'm writing it that way so that there is no confusion). That's completely different of what I'm interested in: Suppose I'm a program, I'm running already, and I want my own location (which is typically not even in the $PATH). ---------------------------------------------------------------------- almafa · 2010-04-19 16:44 Whatever. I have no idea what /proc/PID/exe links (on Linux) in that case, most probably the one you started. Anyway, in the typical use case, an end-user software (who has no control about how you started it) wants to find itself, and there are no hard linked "copies" of it. ---------------------------------------------------------------------- puffybaba · 2010-04-20 00:04 Oh... In that case, I am totally in the dark. ---------------------------------------------------------------------- lteo · 2010-04-20 16:37 When you're in "top" interactive mode, press C (uppercase C) Another way: top -C ---------------------------------------------------------------------- lteo · 2010-04-20 16:38 Does this help? pgrep -fl *process_name* ---------------------------------------------------------------------- almafa · 2010-04-20 18:06 No. Example: # pgrep -fl bash 24075 bash ---------------------------------------------------------------------- almafa · 2010-04-20 18:09 Unfortunately I cannot copy-paste from the badly installed virtual machine I have here, but `top -C` gives the path only for some processes (eg. `/usr/libexec/gettty`), but not all of them (eg. `bash`). ---------------------------------------------------------------------- lteo · 2010-04-21 18:29 You're right. I always start my own programs with the full path, so "top -C" has always "worked" for me. :) Out of curiosity, what is the exact problem you're trying to solve? Perhaps there may be a way to solve it without getting the full path of the running process. ---------------------------------------------------------------------- almafa · 2010-04-21 18:38 The exact problem is getting the full path of the running process. I wrote a small cross-platform library doing exactly and only this. Now, my notion of cross-platform was OSX/Windows/Linux, but then unfortunately some people started to use it, and because of that sometimes some other people complain that it does not work, and now I'm in this messy situation :) But I'm starting to suspect that it is actually not possible to solve on some system/configuration pairs... ---------------------------------------------------------------------- I_Met_Bubb-Rubb · 2010-04-22 06:43 How about? lsof | grep bash This will show you the open files that contain bash in the name or path. ---------------------------------------------------------------------- almafa · 2010-04-22 18:57 # lsof bash: lsof: command not found # pkg_add lsof Can't resolve lsof It seems that OpenBSD does not have lsof. I tried fstat, but it seems to me that running programs are not held open. Also, suppose it is opened; how do you identify which file is the executable you want? I guess it's not opened by itself, so the PID does not help; but even among the list of files opened by the program itself, I don't see how you would identify it... ---------------------------------------------------------------------- I_Met_Bubb-Rubb · 2010-04-22 21:57 I am having a little difficulty understanding what open files you are looking for, but lsof may or may not be what you want. I did find an article which describes how to install lsof on OpenBSD if you want to try. It looks easy enough, although I have never used OpenBSD. [lsof on OpenBSD](http://www.openbsd101.com/tipstricks.html#tt10) EDIT: If you do install lsof let me know if it worked for what you need. ---------------------------------------------------------------------- almafa · 2010-04-23 06:26 I'm not looking at all for open files. I think I wrote down pretty clearly, multiple times in this thread, what is the problem I would like to solve: Suppose I'm a running process, I want to find out my own path. But lsof lists the open files, according to your post, and I tried to think aloud about whether lsof has any chance to help or not. ---------------------------------------------------------------------- lteo · 2010-04-25 17:09 How did you find the full path in OSX? That's BSD too, so there might be a similar approach in OpenBSD or the other BSDs that are not doing this right now. ---------------------------------------------------------------------- almafa · 2010-04-25 18:07 I used OSX-specific calls on OSX (surprise!). Namely, * CFBundleGetMainBundle * CFBundleCopyExecutableURL * CFURLCopyFileSystemPath CF stands for Core Foundation. ---------------------------------------------------------------------- edwtjo · 2010-04-30 09:44 On FreeBSD 7.2+ procstat -f Is your friend. This is can be used to get the CWD, or other stats. ---------------------------------------------------------------------- almafa · 2010-05-03 17:28 if you read the original post, you would know that the problem is solved for freebsd >= 6.0 (the post actually contains the solution). ---------------------------------------------------------------------- masta · 2010-05-18 21:28 the posix realpath() function in the standard library on the argz? BSD even has a realpath command, I think, along with basename, and dirname. Anyhow the pwd variable should be initialized for all running processes. Not sure how to get at that one though. will have to think about this more. will reply if find out. ---------------------------------------------------------------------- almafa · 2010-05-19 21:27 i assume that by argz you mean argv[0]. As the goal is to have this functionality in a library, it does not have access to argv[0] (because of some oddity of the target system, it does have access to the program name though, without the path). Also, as far as i remember, there is no guarantee that `realpath(argv[0])`, or `realpath( currentdirectory/ argv[0] )` is actually the path of the executable. What you mean by "the pwd variable"? Getting the current directory is not a problem.