Missing the reason

Posted Sep 7, 2025 17:01 UTC (Sun) by mb (subscriber, #50428)
In reply to: Missing the reason by mirabilos
Parent article: No more 32-bit Firefox support

Using the 32bit version of an application just for limiting its memory use sounds like using a hammer as tool for a problem where you'd actually need to use a screw driver.

Have you looked into cgroups for limiting the memory consumption of applications?
That would even work with multi process applications.

Missing the reason

Posted Sep 7, 2025 18:06 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (14 responses)

No, I’ve had enough trouble to get libvirt and/or Docker working because they want to use cgroups, and I’ve never saw any useful docs for how to use them other than “just use systemd, man, it’ll do it automagically for you”, and then there’s the v1 vs. v2 issue…

Missing the reason

Posted Sep 7, 2025 18:49 UTC (Sun) by mb (subscriber, #50428) [Link]

Reminds me of this:
https://xkcd.com/1172/

Missing the reason

Posted Sep 11, 2025 10:48 UTC (Thu) by kpfleming (subscriber, #23250) [Link] (6 responses)

I believe 'systemd-run' can do this now - launch any executable, creating a cgroup to contain it, and set various limits including memory usage. It may be worth a try.

Missing the reason

Posted Sep 11, 2025 13:00 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

`systemd-run` has been able to do this for a long time. I've used it to make sure a build doesn't require more than 4 GB per TU by running a non-parallel build under a strict memory limit. But, AFAIK, it does require using systemd as your init system (or, rather, cgroup manager), so perhaps systemd-run is the "just use systemd, man" solution alluded to here.

Missing the reason

Posted Sep 11, 2025 22:27 UTC (Thu) by mbunkus (subscriber, #87248) [Link]

It sure can. It's as easy as:

systemd-run --user --property=MemoryMax=16G firefox

Missing the reason

Posted Sep 11, 2025 22:49 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (3 responses)

Note the part in the comment you replied to which says:

> never saw any useful docs for how to use them other than “just use systemd, man

You fulfilled the cliché beautifully, though, I’ve to admit.

(No, I don’t and won’t run systemd, period.)

Missing the reason

Posted Sep 12, 2025 6:08 UTC (Fri) by zdzichu (guest, #17118) [Link] (2 responses)

You have to drive a nail in the wood. People say "just use a hammer, man". And you are like "never hammer, I will manage with this round rock somehow". It's your fault you ignore tools, so stop complaining.

Missing the reason

Posted Sep 12, 2025 15:03 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (1 responses)

Except systemd is not the hammer; systemd is a cheap asian version of a swiss army pocket knife, with too many functions bundled.

Missing the reason

Posted Sep 12, 2025 20:58 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Like, Linux itself?

Missing the reason

Posted Sep 11, 2025 13:49 UTC (Thu) by intelfx (subscriber, #130118) [Link] (2 responses)

> because they want to use cgroups, and I’ve never saw any useful docs for how to use them other than “just use systemd, man, it’ll do it automagically for you”

Well, cgmanager exists (or, at least, existed). In its time it was absolutely a viable alternative to systemd, and docker used to support both. The upstream development stopped in 2020, presumably because nobody wanted to do it anymore.

It’s hardly systemd’s fault that it turned out so good nobody actually desired to continue developing the alternatives.

> and then there’s the v1 vs. v2 issue

There is no issue. One is obsolete, other is actively supported.

Missing the reason

Posted Sep 11, 2025 22:52 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (1 responses)

Hm, no cgmanager in Debian (bullseye, but likely not trixie either).

> > and then there’s the v1 vs. v2 issue
>
> There is no issue. One is obsolete, other is actively supported.

Who cares about supported?

The issue is that some software will only work with one of them. (I *think* I had to mkdir and mount cgroups v1 stuff in trixie to get… something… to work, Docker maybe or libvirt).

Missing the reason

Posted Sep 11, 2025 23:23 UTC (Thu) by intelfx (subscriber, #130118) [Link]

> Hm, no cgmanager in Debian (bullseye, but likely not trixie either).

Precisely. Case in point.

> Who cares about supported?

Those who write the code that you complain about.

Missing the reason

Posted Sep 13, 2025 17:11 UTC (Sat) by donald.buczek (subscriber, #112892) [Link] (2 responses)

> cgroups, and I’ve never saw any useful docs for how to use them other than “just use systemd, man, it’ll do it automagically for you”

You and most people will probably already know this, but of course you can also use cgroups without any special software by manipulating the files and directories in /sys/fs/cgroup (or wherever else you mount the cgroup2 filesystem).
Everything is documented at https://docs.kernel.org/admin-guide/cgroup-v2.html.

However, I don't know whether this helps in the context of libvirt and Docker. I'm not familiar with them and don't know what their requirements are.

Missing the reason

Posted Sep 13, 2025 17:38 UTC (Sat) by mirabilos (subscriber, #84359) [Link] (1 responses)

I did in fact not know that; I hadn’t researched into cgroups in more detail.

Much appreciated.

Missing the reason

Posted Sep 16, 2025 7:11 UTC (Tue) by taladar (subscriber, #68407) [Link]

You might want to have a look at the cgroups(7) manpage to get an introduction to cgroups in general.