Memory caps, run time limits, sleep inhibitors, better cron and path units - systemd features that turn out to be handy for running throwaway agent-written code.
It is possible to limit the bandwidth for writing on the storage device with systemd-run, but not to limit the network bandwidth used by the programm (as far as I know)
Yes and as I said there is no way to limit the network bandwidth, as far as I know, but limiting the speed that the tool can write to the storage device oftentimes limits the speed of retrieval also.
Kind of a indirect speed limit for the download, as a workaround.
Ah, I didn’t pick up on that. Well, need to test this out. As a workaround it could work. I don’t have any other special requirements for this, its really a workaround in itself for tools that don’t have this setting. (which annoys me alot) Nice idea btw.
There is an ancient fully user-space simple tool called netbrake that works by LD_PRELOADING a library that overrides some functions like recv/sendto (similar to eatmydata’s approach*). It may just work if you don’t have special requirements. If you’re curious, you can see the full list of overridden symbols with:
readelf -s /path/to/libnetbrake.so | grep -v UND
If you want a possibly fail-safe (kernel level) solution, you may find with a web search a helpful approach combining tc with cgroups.
Neither solutions need systemd.
* The realization that people growing up with SSD’s probably never heard of eatmydata just sunk in.
Thanks for the tip. I will look into it. My use case would be to limit download speed for applications that do not have such a setting (such as Firefox, just an example).
It is possible to limit the bandwidth for writing on the storage device with systemd-run, but not to limit the network bandwidth used by the programm (as far as I know)
The property for I/O bandwidth would be IOWriteBandwidthMax https://www.man7.org/linux/man-pages/man5/systemd.resource-control.5.html
The commandline option to use it with is --property= https://www.man7.org/linux/man-pages/man1/systemd-run.1.html
That’s not the same as network bandwidth. Maybe I used the wrong terminology, I meant download speed, not max downloaded size of data contingent.
Yes and as I said there is no way to limit the network bandwidth, as far as I know, but limiting the speed that the tool can write to the storage device oftentimes limits the speed of retrieval also.
Kind of a indirect speed limit for the download, as a workaround.
Ah, I didn’t pick up on that. Well, need to test this out. As a workaround it could work. I don’t have any other special requirements for this, its really a workaround in itself for tools that don’t have this setting. (which annoys me alot) Nice idea btw.
There is an ancient fully user-space simple tool called netbrake that works by LD_PRELOADING a library that overrides some functions like recv/sendto (similar to eatmydata’s approach*). It may just work if you don’t have special requirements. If you’re curious, you can see the full list of overridden symbols with:
If you want a possibly fail-safe (kernel level) solution, you may find with a web search a helpful approach combining tc with cgroups.
Neither solutions need systemd.
* The realization that people growing up with SSD’s probably never heard of eatmydata just sunk in.
Thanks for the tip. I will look into it. My use case would be to limit download speed for applications that do not have such a setting (such as Firefox, just an example).
You can use the cliget extension which generates full CLI commands for major CLI tools. Such tools have many options (e.g. curl’s --rate-limit).
Firefox was just one example of tool that doesn’t provide a limit by itself. I’m looking for a solution that could be applied to any program.