> Well, then the stategy is not to have a strategy, which is perfectly fine.
The strategy is to teach the principle of not over commiting.
> It still doesn't matter for the use case under discussion here. The "bug"
> reporter expected some OOM type situation, and didn't observe any, because
>
On Tue, 2023-05-16 at 06:33 -0600, Theo de Raadt wrote:
> Rudolf Leitgeb wrote:
>
> > Lots of people (including myself) come from linux background and use
> > OpenBSD for specific security sensitive tasks. Since OpenBSD, like
> > every other desktop OS these days, has some strategy to deal
> >
Theo de Raadt wrote:
> Rudolf Leitgeb wrote:
>
> > Lots of people (including myself) come from linux background and use
> > OpenBSD for specific security sensitive tasks. Since OpenBSD, like
> > every other desktop OS these days, has some strategy to deal
> > with OOM conditions, the term
Rudolf Leitgeb wrote:
> Lots of people (including myself) come from linux background and use
> OpenBSD for specific security sensitive tasks. Since OpenBSD, like
> every other desktop OS these days, has some strategy to deal
> with OOM conditions, the term "OOM killer" is perfectly clear
>
On Tue, 2023-05-16 at 09:16 +0100, Stuart Henderson wrote:
> The strategy is that the sysadmin should configure datasize limits so
> that processes hit memory allocation failures if they try to
> overreach.
> Defaults are setup with typical use-cases and machines in mind but
> you
> might know
On 2023/05/16 09:12, Rudolf Leitgeb wrote:
> Lots of people (including myself) come from linux background and use
> OpenBSD for specific security sensitive tasks. Since OpenBSD, like
> every other desktop OS these days, has some strategy to deal
> with OOM conditions, the term "OOM killer" is
Lots of people (including myself) come from linux background and use
OpenBSD for specific security sensitive tasks. Since OpenBSD, like
every other desktop OS these days, has some strategy to deal
with OOM conditions, the term "OOM killer" is perfectly clear
regardless of what the actual
On 2023/05/15 19:55, bugreport555 wrote:
> Ok, I tested it in various ways and tried to force OOM killer to step in but
> it never did and all worked fine.
OOM killer? This isn't Linux.
Ok, I tested it in various ways and tried to force OOM killer to step in but it
never did and all worked fine.
So yeah, this is not a bug. Shame you can't somehow force to clear the cache
and see actual ram use. It can look disturbing.
--- Original Message ---
On Monday, May 15th,
everything remains fine.
On Mon, 2023-05-15 at 09:10 +, bugreport555 wrote:
> > Synopsis: Some programs appear to cause system to leak memory, fill
> > ram
> > Category: system amd64
> > Environment:
> System : OpenBSD 7.3
> Details : OpenBSD 7.3 (GENERIC.MP) #1125:
>Synopsis: Some programs appear to cause system to leak memory, fill ram
>Category: system amd64
>Environment:
System : OpenBSD 7.3
Details : OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Arc
Synopsis: Some programs appear to cause
system to leak memory, fill ramCategory:
system amd64Environment:
System : OpenBSD
7.3 Details :
OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT
2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture:
12 matches
Mail list logo
