-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thank you for your insight!
On 07.09.2015 13:32, Robert Elz wrote: > Date: Mon, 07 Sep 2015 12:24:58 +0200 From: Kamil > Rytarowski <n...@gmx.com> Message-ID: <55ed65fa.1000...@gmx.com> > > | I'm here to get the support for it. At the moment it (cache nits) > | exceeds my comprehension too. > > What is the semantic you're hoping to provide? The path that was > used to exec the process, or the path that would be used now to > get the same one? [The difference is if the binary has been > (re)moved between when it was exec'd and now.] > The path that was used to execute the process. sysctl(7) can fail gracefully and its collapse is easier to maintain (through the proper interface) then almost undefined behavior of /proc/PID/exe. > The exec time path is easier, and must exist (or the exec would > have failed), the current path is more useful, but not guaranteed > to exist, and much harder to find. > I'm completely OK with possible failure if the file was moved or removed . I don't see need to scan the disk for its possible new location or name. I prefer to receive failure then get it unexpectedly located somewhere else. > Which is wanted depends upon what the real purpose of this is - if > it is just to replace the entry in /proc then before doing that > ask what use that has - does anything really use it, and if so, > for what, and how well does it work. > I started to search for its usage (readlink over /proc/PID/exe): 1. gdb 2. lldb 3. valgrind 4. Chromium 5. tup 6. GNUStep-base 7. Wireshark 8. Firefox 9. Openglad 10. Alcextra 11. Cafu 12. Caster 13. Physfs 14. jruby-launcher 15. CDE And then I stopped as there was a set of over 100 more Open Source projects. [1] What's the use of /proc/PID/exe, for this please let me cite the comment from CDE [2]: // super hack! if the program is trying to access the special // /proc/self/exe file, return perceived_program_fullpath if // available, or else cde-exec will ERRONEOUSLY return the path // to the dynamic linker (e.g., ld-linux.so.2). // // programs like 'java' rely on the value of /proc/self/exe // being the true path to the executable, in order to dynamically // load libraries based on paths relative to that full path! char is_proc_self_exe = (strcmp(filename, "/proc/self/exe") == 0); // another super hack! programs like Google Earth // ('googleearth-bin') access /proc/self/exe as /proc/<pid>/exe // where <pid> is ITS OWN PID! be sure to handle that case proper ly // (but don't worry about handling cases where <pid> is the PID of // another process). // // (again, these programs use the real path of /proc/<pid>/exe as // a basis for dynamically loading libraries, so we must properly // 'fake' this value) char* self_pid_name = format("/proc/%d/exe", tcp->pid); > Others have been suggesting that the use is for debuggers (gdb or > whatever). If that's it, and the only reason, then personally I'd > just forget it. If someone is debugging a process, but can't even > work out where the binary is (or is too lazy to type it) then I'd > suggest that they ought to just give up... > > On the other hand, if it is so the debugger can verify that it is working > from the correct binary file, then the pathname isn't needed, just > the <dev, ino> pair, which is the true name of a unix file > (pathnames are just a human interface improvement ... and a bit of > added security). With just that, the debugger can verify that the > file running (assuming that > sysctl (or /proc) provide that info) is the one that the user told them is > to be debugged, and issue a warning (or whatever) if the don't > match. > > Alternatively, perhaps there's some other use ? > > kre > This sysctl(7) happened to be handy for libproc, as a missing puzzle for our userland DTrace support. I don't want to focus on every legitimate usage, as there set of software using it is very wide; I would focus now on rather providing the software -- in my case lldb(1) - -- what it expects and let it process further. To sum it up, the overview gave me the idea that proc.PID.realpath: - - must be absolute path, - - preferably canonicalized (links, '.' and '..' resolved) - if so then call it .realpath, if not then .pathname (to be compatible with FreeBSD) , - - pathname of the execution time, - - missing, moved, removed or replaced file - let the consumer of this interface handle it on his or her own. There are in-kernel issues with long path names, as we store limited number of characters. I would leave this as it is, as the current limits handle sane number of characters (PATH_MAX is 1024 [3]) for most normal use-cases. Both narrow cases (alteration to the executable) and pathname limits should never happed in a properly designed software and environment. Why to add another interface for the same thing? - - safety (hide pathname from unprivileged users), - - stop depending upon hard-coded path of procfs and its existance, - - easier error handling through C-language level interface. My personal use-case is to have full-featured lldb(1) in a procfs-less system. This includes standard usage, not walk-arounding environment problems. [1] According to https://searchcode.com [2] https://searchcode.com/codesearch/view/96415437/#l-1072 [3] src/sys/sys/syslimits.h -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV94lzAAoJEEuzCOmwLnZsu+8P/iusHPrqZsEzJ5/qmAuc51+3 VcZM3nptpGFJ9g/gg25LuSj21I1+b+NyIEbpLsTYYcXbfaWfbRD4LlYoRLwP9kLa yPfMiDWOJ5DWRigF674AZiRIC/TUzB4ECCVNfHe8twXcpGMIyiqtJITAKwfSBXeV RpBUc8HusDohRZybEJbJjwLH7GIugvUnoPLoBTB/QTMjs9orjuIu0EU7oDAAZnxY tCkxH43fXmfmoL+UPavoIh7nD0Z6avPCk29cKodnrMEIR0m7CgtvVPdo/cdrgy6p /yEndy555KtmG3oFO3qeXsrKiquylpzSx2K1fl921n5bgOGxSoVhkMmJ5RxQfkuV GbbFU8efoDe4s8QnGm+p93nUIq+OQZMNc5M75mkIu2VkU4BcBcCdBywXoQCAvTh7 MMXQ8e7xddw/ZgG9MaadqS+hwEnrfgMBFsjlbC2LyL8QWYjNai7GSy++ETjx28vY Tzvi6fT2jQTCHaKl+8mKAR3oRlTSUL/omqSbtkb5D0doq2olWxU3l4aPECz69Mmm VteBBJfKSdyWPcWAD4fGCbh0QiPDwCZGp7fsuaAfgfUqhyEEWWs/8H+4cOFYf2Ir RIzWn7equf0cTkHu/5Sq+sm0W1M77xL6i2AksE2i5uG18Wcv0p02lfgU/yvtLRUa tVJqJp751FBn1qnvngDd =Sqjh -----END PGP SIGNATURE-----