Re: A per-user or per-application ld.so.cache?

["Carlos O'Donell" <carlos at redhat dot com>]

On 02/08/2016 02:11 PM, Siddhesh Poyarekar wrote:
> On Mon, Feb 08, 2016 at 01:40:05PM -0500, Carlos O'Donell wrote:
>> Under what conditions might it make sense to implement
>> a per-user ld.so.cache?
>>
>> At Red Hat we have some customers, particularly in HPC,
>> which deploy quite large applications across systems that
>> they don't themselves maintain. In this case the given
>> application could have thousands of DSOs. When you load
>> up such an application the normal search paths apply
>> and that's not very optimal.
>>
>> Might it make sense to have a per-user ld.so.cache for
>> this case? Might we even entertain a per-application
>> ld.so.cache?
> 
> It won't be a bad idea as long as it is ignored when running setuid
> binaries.
> 
> The other alternative could be extending ld.so.cache to have profiles
> for specific binaries in the system path.  That is, enhance the format
> of files in /etc/ld.so.conf.d/ to have a regular expression (or maybe
> even simple wildcards) in the beginning that specifies binaries that
> will use these paths first.  IIRC we do something similar for hwcaps.
> 
> This should also improve performance marginally for applications that
> don't need all of those library paths that the files in ld.so.conf.d
> add.  It will also help maintain a clean namespace in cases where two
> installations may have DSOs with the same names but in different
> paths.

The downside is that the user has no control of this cache and
would need administrative intervention for help accelerating their
application. Consider that you bought time on a cluster of machines,
and now to run your app you're making the user interact with the sysadmin
to install new filters and run ldconfig on every node? It won't scale
(from a human perspective).

With a per-user/per-proces cache say in ~/.ld.so.cache, the user could
prime the cache themselves after setting up their application with
bundled libraries and have it work as expected, but accelerated lookups
without lots of stat/getdents in $HOME.

Does that counter-argument make sense for why the cache could be
under user control? It means the data needs to be inspected carefully
though.

Cheers,
Carlos.