> 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
> the
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&server OS these days, has some strategy to dea
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&server OS these days, has some strategy to deal
> > with OOM conditions, the te
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&server 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 bett
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&server OS these days, has some strategy to deal
> with OOM conditions, the term "OOM killer"
Lots of people (including myself) come from linux background and use
OpenBSD for specific security sensitive tasks. Since OpenBSD, like
every other desktop&server OS these days, has some strategy to deal
with OOM conditions, the term "OOM killer" is perfectly clear
regardless of what the actual im
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, 2023
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 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
12 matches
Mail list logo
