trickled
uses the same technique to limit bandwidth as trickle
. It just listens on a UNIX domain socket in /tmp
for other trickle
processes. When another trickle
process starts up, it will ask trickled
(if it is running) for the global settings, and set these as defaults, unless it has individual overrides for that specific instance of trickle
.
A fully statically linked executable (meaning that everything, including libc, is statically compiled into the binary) can't be used with a userspace process like trickle
. What eventually happens with a statically linked executable is that it makes system calls directly into the Linux kernel's stable user<->kernel Application Binary Interface (ABI). It does not attempt to load any libraries within /lib
, /usr/lib
, /usr/local/lib
, etc. to resolve symbols.
The magic of trickle
is that it effectively injects custom code into processes that do dynamically load the C library from the system. Processes that don't, or processes that are setuid root, can't have their code modified in this way.
To truly control all processes on the system, this level of bandwidth limiting would need to be done in the kernel itself.
There are a few kernel implementations, both old and new, of traffic shaping functionality (traffic shaping is the generalized term for bandwidth limiting, and it generally means modifying the timing or scheduling of packets) in the Linux kernel itself, and these are much more reliable. here is a more recent example based on the nf framework, which is slated to replace iptables as the layer 3 policy and control stack for modern Linux.
Not sure how you are getting trickle. It was last maintained by the upstream in 2003. Debian has a ~1 MB patch against it that they maintain, which I guess keeps it functional on modern distros. – allquixotic – 2014-01-14T14:17:46.403