Scott Schmit writes:
On Mon, Jul 16, 2012 at 07:38:52PM -0400, 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".
And what's the pathname of a deleted file?
My point exactly. There is none. Thanks, prelink! ...
That's the interface you've got. Playing around a bit, what it looks
That's a very nice explanation. Unfortunately, all of these semantics are not under question. That's not the issue.
like you want to do is open("/proc/self/exe", O_RDONLY), fstat the
resulting file descriptor, and use the device+inode to compare to the
"other" executables.
Which will, of course, be different. Because prelink rewrote and renamed the executable. I'm not exactly sure what point you were trying to make, other than prelink being broken by design.
The device+inode can't be reused while you're
executing, so you know that the other program is using the same
executable
No, it's not using the same executable. The executable has been replaced by prelink, and the executable is now different, even though it is, really, the same executable. Nothing has been installed, or upgraded.
Expecting every other program that manipulates/replaces files to cater to your expectations is not reasonable unless you have 100% control over everything that runs on your system (and take full responsibilty for controlling it) and likewise for anyone else using the software.
True. That 100% control, of course, includes uninstalling the pest that keeps rewriting executables, any time it feels like it.
Even
then, the time would be better spent changing your software to use the
interface correctly (or use a more appropriate one) so you never have
problems.
Can you explain, then, the "correctly" approach by which an executable can affirm whether another pid is either running the same executable, or the post-prelinked version of the same executable. Anyone who suggests readlink- ing /proc/self/exe, then the other /proc/pid/exe, and comparing them sans any hardcoded " (deleted)" suffix is going to get only howls of laughter, in response.
P.S. I have an internal betting pool going on when some top gun offers a suggestion of running prelink --verify on both exe-s (since you can still open a " (deleted)" exe, inexplicably, even though the actual symlink points to nowhere), and comparing the results.
P.P.S. And I'm still trying to process the concept of a symbolic link pointing to a non-existent pathname; yet an open() on that somehow succeeds, nevertheless. That's one a headscratcher, even though I'm told that's how "UNIX" worked for decades. You always learn something new.
Attachment:
pgpamHqnilBEU.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
