Bryn M. Reeves writes:
On 07/17/2012 12:42 PM, Sam Varshavchik wrote:
> … which can be used to reset the
> application, so that it knows that it's been updated.
Because that is a common need across many packages.
Apparently being notified of a prelink is not such a common need. Even
if such a thing did exist it could not protect you from any other
modifications to the binary if it was specific to prelinking so you
would still need to handle this case to avoid bugs in your program.
I'm having some kind of a difficulty parsing the above. How exactly would
some kind of a notification that your executable has been prelinked would
not be effective for modifications that result from prelinking.
Maybe you would find more acceptance for a request asking for
something
like this rather than demanding the removal of something that has been
used for many years and that has good evidence for the benefits it
claims to provide?
I don't recall myself demanding anything. I described a problem that prelink
is causing, namely invalidation of the contents of the /proc/self/exe
symlink. I also floated some alternatives, like skipping binaries that are
currently running.
I see little sense in demanding something that can already be easily done
anyway, like removing prelink altogether, or by blacklisting a selected
executable, which is trivial to implement. I just thought – and as I said,
that this is not solving the problem, but sweeping it under the rug, and
that there should be a better way to avoid having prelink break
/proc/self/exe.
> If you tell me how an app can be notified that prelink is about to rewrite
> it, then this would be a comparable situation. But it's not.
Inotify?
If you care about it in your app (and since nobody else appears to have
asked for it I'd argue that's a good sign that there is not yet any
justification for a general facility like this) perhaps you should look
at inotify and register a watch for your executable's inode so that you
can take appropriate actions?
This would also deal with modifications other than prelinking.
I'm dying to know what other "modifications" are there, other than
prelinking – inquiring mind wants to know. And the coin can be flipped both
ways too: AFAIK nothing else other than prelink randomly scribbles over
random executables. Somehow, things have been fine all along, before prelink
came along, and perhaps, some consideration could've been provided for
applications to use and integrate with.
You could even make such a thing into a library that other
developers
could use to solve the same problem. If there's widespread need for the
facility I'm sure you'd soon have plenty of users and a good
justification to get it included in distributions.
That's generally how things move forward in open source.
Thank you for telling me what I've already done. But, it would've been great
to avoid dealing with prelink's broken design in the first place.