More obvious, but systemd has a lot of features that a simple cron doesn't.

Which cron?

Oh wait. Why did I assume OP would know there are multiple implementations? 😄

You may have experienced this before. You have an agent write a script, perhaps to do some data analysis. It has a terrible memory leak, and suddenly your machine freezes and (hopefully) the kernel resumes after a bit with an OOM error I've had this a few times, and it's very annoying..

Holy fuck I can't stop laughing at their reason for systemd for some reason, probably need an agent summarising their article for me

This has been happening forever. This old post always pops up in my mind for some reason as a historic example from an earlier linux boom.

Unfortunately, people have been pushed to not call out such things, because it's "not nice", when as the blog above shows, not calling it out is what's not nice, and potentially dangerous.

I remember way back when I was doing Ruby on Rails, we would always wrap the server processes in a manager (I forgot what it’s called) that watches the memory and restarts them when the leaks get too bad. What a ridiculous solution that was.

He also implies that cgroups are a systemd-only feature.

Is there a way to limit download bandwidth of programs started with this systemd-run command? Without changing some network settings, I just want to do it temporarily on the fly with commandline options.

Yeah. I called out someone here on Lemmy for just completely making shit up about some kernel feature, linked the documentation showing the actual meaning, and got downvoted for it.

But to be fair, systemd makes using cgroups stupidly easy

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.

I mean, the only thing i needed cgroups for was running rootless containers on Alpine (Openrc). This was something like cgroups = true in their main config. Can it be easier?

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.

Ok and now tell me how to use cgroups for a random binary, anything that has not buildin cgroups support.
That's were it gets complicated and where systemd can help a lot

You are using a tool where someone else has solved the hard part to show that no hard part exists in the first place.

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).

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.

such as Firefox

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).

what is cgexec 🤔

Yes, that is one of the tools needed.
But it is not helping with doing anything meaningful with cgroups.
A cgroup without any kind of specific configuration is almost as good as no cgroup at all.
That's what I meant with the hard part.

And I did say that systemd makes it stupidly easy, in contrast to the normal easy that cgroups often are.

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.

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.