Re: [RFC] per-containers tcp buffer limitation

On Thu, Aug 25, 2011 at 11:27 AM, Daniel Wagner [off-list ref] wrote:

Hi Chris,

On 08/25/2011 05:05 PM, Chris Friesen wrote:

quoted

On 08/25/2011 06:55 AM, Daniel Wagner wrote:

quoted

I'd like to solve a use case where it is necessary to count all bytes
transmitted and received by an application [1]. So far I have found two
unsatisfying solution for it. The first one is to hook into libc and
count the bytes there. I don't think I have to say I don't like this.

Is there any particular reason you can't use LD_PRELOAD to interpose a
library to do the statistics monitoring?

This is certainly possible to do for any dynamic linked application. I
think it wouldn't work for static linked ones. Currently I don't know if
I have to face such application on the project I am on. The reason why I
am not so a big fan is that using the LD_PRELOAD trick seems very
hackish to me.

LD_PRELOAD is widely regarded as a debugging and tracing method -- it's not
usually suitable for implementing features. Why? Because there's nothing
stopping an application from resetting LD_PRELOAD and re-exec'ing to escape
the measurements and limitations such a preload implements. Plus naive use
of LD_PRELOAD could easily interfere with other things that use it. For
example what if you want to use DMTCP with this?

Cheers,
    -Matt

From: Matthew Helsley <redacted>
Date: Sat, 27 Aug 2011 16:39:11 -0700

LD_PRELOAD is widely regarded as a debugging and tracing method -- it's not
usually suitable for implementing features. Why? Because there's nothing
stopping an application from resetting LD_PRELOAD and re-exec'ing to escape
the measurements and limitations such a preload implements. Plus naive use
of LD_PRELOAD could easily interfere with other things that use it. For
example what if you want to use DMTCP with this?

LD_PRELOAD is also terrible as a "normal" facility because it breaks
prelinking.