Christopher Waldon Christopher Waldon - 2 months ago 15
HTTP Question

Why doesn't the trickle utility affect my dynamically-linked golang program?

I have a golang program that uploads a ton of data to OpenStack Object Storage over https. It relies on the golang standard library

to do the work. I would like to use
to rate-limit the upload of the data, but running my code using trickle does not seem to have any effect (as though I'm not using trickle at all).

Why does this happen? Is there some limitation to trickle or golang that prevents them from working together? Is there some gotcha that I haven't considered?

This is my setup:

I know that
only works on dynamically-linked executables (see first paragraph of trickle documentation), so I've compiled my code with
go build -compiler gccgo mycode.go
and the output of
ldd myexecutable
is: => (0x00007ffee27b8000) => /usr/lib/x86_64-linux-gnu/ (0x00007f46062bf000) => /lib/x86_64-linux-gnu/ (0x00007f46060a9000) => /lib/x86_64-linux-gnu/ (0x00007f4605cdf000)
/lib64/ (0x000055aa4d0a4000) => /lib/x86_64-linux-gnu/ (0x00007f4605ac2000) => /lib/x86_64-linux-gnu/ (0x00007f46057b9000)

I'm running this on Ubuntu Linux 16.04. I use
to view the network traffic as my command runs. The machine isn't running any other network-intensive jobs, so I'm confident that I'm seeing the traffic generated by my code.

When I run

trickle -s -v -u2500 myexecutable ...args

I see my TX network traffic spike to about 12000KB/s (the maximum that the network can handle) instead of respecting my limit of 2500KB/s.

Can anyone think of why this might happen or what I could try to fix it?


Trickle relies on using LD_PRELOAD to replace all network related calls through libc with its own implementation. This is why trickle doesn't work with static binaries.

Go makes all its own syscalls directly and does not use the libc interface, so the inter-positioned functions provided by trickle are not used.