prelink should not mess with running executables

[Sam Varshavchik]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120717/b3969cc1/attachment.sig>