On 07/17/2012 12:38 AM, Sam Varshavchik wrote:
> Jan Kratochvil writes:
>
>> On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
>>> And I wouldn't be so presumptions as to state authoritatively what
>>> is or is not a bug, in something whose purpose is not known to me.
>>
>> Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX
>
> It is anything but "normal". The "normal" state of things is documented by
> proc(5). As documented by that man page, rather plainly,
> readlink("/proc/self/exe") gives you your own pathname. That's the "normal"
> state of things, if "normal" means anything. When that no longer holds true,
> that's not "normal".
As others have pointed out it is a normal situation that the system has
to deal with; there's no escaping it on a UNIX-like OS and a developer
can never depend on it not happening at "random" times.
The pathname that is returned to readlink(2) doesn't exist in the file
system (how could it?) but the proc path is still valid for IO and the
inode will not be de-allocated while it is open:
$ cp /bin/vim /tmp
$ /tmp/vim foo
$ ps ax | grep foo
8904 pts/3 S+ 0:00 ./vim foo
8960 pts/4 S+ 0:00 grep --color=auto foo
$ rm /tmp/vim
$ readlink /proc/8904/exe
/tmp/vim (deleted)
$ cat /proc/8904/exe > /tmp/vim.out
$ ll /tmp/vim.out
-rw-rw-r--. 1 breeves breeves 2097656 Jul 17 09:41 /tmp/vim.out
$ file /tmp/vim.out
/tmp/vim.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=0x695009d204a46dd413af6afc12207ee5f21fabf5, stripped
$ md5sum /tmp/vim.out
21f4752d9efdb68e6af1ff22b2652fde /tmp/vim.out
$ md5sum /bin/vim
21f4752d9efdb68e6af1ff22b2652fde /bin/vim
$ prelink -u -o - /tmp/vim.out | md5sum
c9b7e38bacad0b1c5e04b6c71a5f45b9 -
$ prelink -u -o - /bin/vim | md5sum
c9b7e38bacad0b1c5e04b6c71a5f45b9 -
If the check you need to make is "is this the same binary?" then surely
it should fail if the binary was actually upgraded? If it was not and
was simply modified by prelink then you should be able to do what you
want by open(2)ing the proc path instead of readlink(2)ing it.
If you're happy to accept something that's a different version of the
binary then I'm not sure why you need to read the executable (what are
you checking in it?). If it's just an inode number match it's hard to
see what that achieves.
> Broken maintenance scripts, of dubiuous benefit, that randomly rewrite
> unrelated binaries, should be fixed.
Suggest fixes. If you're doing something unusual the onus is on you to
justify why the system should conform to your expectations instead of
the expectations it's currently designed for.
Regards,
Bryn.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
