Bryn M. Reeves writes:
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;
No, I'm afraid it's not "normal", by any sense of the word, for something to randomly delete executables, and replace them with similarly looking files.
there's no escaping it on a UNIX-like OS and a developer
Yes, there's certainly a guaranteed way to "escape" it. It's called "don't do stupid things". What a novel concept.
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:
Except that's not what proc(5) says. As described, reading that symlink should give you the executable's name. Except, in this situation, it no longer does. It points to a non-existent pathname. The fact that by some miracle of miracles an open() on a non-existent pathname manages to succeed, is an irrelevant sideshow.
If you're happy to accept something that's a different version of the binary
I'm not.
then I'm not sure why you need to read the executable (what are
When did I ever said that I needed to read the executable?
you checking in it?). If it's just an inode number match it's hard to see what that achieves.
Just because you find it hard to see "what that achieves", means only that: you find it hard to see.
> 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
Well, I did.
Attachment:
pgpMmSPlJB9Wq.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
