From mboxrd@z Thu Jan 1 00:00:00 1970 From: arisawa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Sun, 25 Jan 2015 15:16:32 +0900 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b55ebd8-ead9-11e9-9d60-3106f5b1d025 Hello 9fans my mac has a protection below: -bash$ cat foo #!/bin/sh ./foo -bash$ ./foo ./foo: fork: Resource temporarily unavailable -bash$ on the other hand, Plan 9 does not. kernel is protected against such programs, however they are not killed. therefore no new process can be created. does anyone have idea to fix the problem? Kenji Arisawa From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----CL7L2ZCD0HA30TVO8FD55VCU8MB49V" Content-Transfer-Encoding: 7bit From: mischief@9.offblast.org Date: Sat, 24 Jan 2015 22:59:18 -0800 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>, arisawa Message-ID: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b5cadb0-ead9-11e9-9d60-3106f5b1d025 ------CL7L2ZCD0HA30TVO8FD55VCU8MB49V Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You would need to implement something like ulimits to fix process exhaustio= n, or some kind of rate limit=2E There are several forms of resource exhaus= tion in plan 9=2E One other that comes to mind is cat /dev/random prevents = other clients from making progress reading /dev/random, such as cpu=2E On January 24, 2015 10:16:32 PM PST, arisawa wrote: > >Hello 9fans > >my mac has a protection below: >-bash$ cat foo >#!/bin/sh >=2E/foo >-bash$ =2E/foo >=2E/foo: fork: Resource temporarily unavailable >-bash$=20 > >on the other hand, Plan 9 does not=2E >kernel is protected against such programs, however they are not killed=2E >therefore no new process can be created=2E > >does anyone have idea to fix the problem? > >Kenji Arisawa ------CL7L2ZCD0HA30TVO8FD55VCU8MB49V Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable You would need to implement something like ulimits= to fix process exhaustion, or some kind of rate limit=2E There are several= forms of resource exhaustion in plan 9=2E One other that comes to mind is = cat /dev/random prevents other clients from making progress reading /dev/ra= ndom, such as cpu=2E

On January 24, 2015 = 10:16:32 PM PST, arisawa <arisawa@ar=2Eaichi-u=2Eac=2Ejp> wrote: 

Hello 9fans

my mac has a protection=
 below:
-bash$ cat foo
#!/bin/sh
=2E/foo
-bash$ =2E/foo=

=2E/foo: fork: Resource temporarily unavailable
-bash$ 
on the other hand, Plan 9 does not=2E
kernel is protected against s=
uch programs, however they are not killed=2E
therefore no new process =
can be created=2E

does anyone have idea to fix the problem?

Kenji Arisawa



------CL7L2ZCD0HA30TVO8FD55VCU8MB49V-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: arisawa In-Reply-To: Date: Sun, 25 Jan 2015 18:04:06 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4D3BDBE7-5023-4870-89E7-0A84C619941A@ar.aichi-u.ac.jp> References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b613862-ead9-11e9-9d60-3106f5b1d025 thank you, mischief. considering after I have posted previous mail,=20 I have come to think that the script below should fail with error and = stop execution. maia% cat foo #!/bin/rc ./foo maia%=20 current rc does not stop execution. probably not due to protection problem by kernel. there must be a bug in rc. Kenji Arisawa > 2015/01/25 15:16=E3=80=81arisawa = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 >=20 > Hello 9fans >=20 > my mac has a protection below: > -bash$ cat foo > #!/bin/sh > ./foo > -bash$ ./foo > ./foo: fork: Resource temporarily unavailable > -bash$=20 >=20 > on the other hand, Plan 9 does not. > kernel is protected against such programs, however they are not = killed. > therefore no new process can be created. >=20 > does anyone have idea to fix the problem? >=20 > Kenji Arisawa >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <4D3BDBE7-5023-4870-89E7-0A84C619941A@ar.aichi-u.ac.jp> References: <4D3BDBE7-5023-4870-89E7-0A84C619941A@ar.aichi-u.ac.jp> Date: Sun, 25 Jan 2015 12:06:54 +0100 Message-ID: From: =?UTF-8?B?QmVuY2UgRsOhYmnDoW4=?= To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c35ccefc662b050d7804fd Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b6acfb2-ead9-11e9-9d60-3106f5b1d025 --001a11c35ccefc662b050d7804fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >there must be a bug in rc. Or maybe it does tail call elimination :) 2015-01-25 10:04 GMT+01:00 arisawa : > thank you, mischief. > > considering after I have posted previous mail, > I have come to think that the script below should fail with error and sto= p > execution. > > maia% cat foo > #!/bin/rc > ./foo > maia% > > current rc does not stop execution. > probably not due to protection problem by kernel. > there must be a bug in rc. > > Kenji Arisawa > > > 2015/01/25 15:16=E3=80=81arisawa =E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A > > > > > > Hello 9fans > > > > my mac has a protection below: > > -bash$ cat foo > > #!/bin/sh > > ./foo > > -bash$ ./foo > > ./foo: fork: Resource temporarily unavailable > > -bash$ > > > > on the other hand, Plan 9 does not. > > kernel is protected against such programs, however they are not killed. > > therefore no new process can be created. > > > > does anyone have idea to fix the problem? > > > > Kenji Arisawa > > > > > > > --001a11c35ccefc662b050d7804fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>there must be a bug in rc.

Or maybe it does tai= l call elimination :)


2015-01-25 10:04 GMT+01:00 arisawa <= arisawa@ar.ai= chi-u.ac.jp>:
thank you, mi= schief.

considering after I have posted previous mail,
I have come to think that the script below should fail with error and stop = execution.

maia% cat foo
#!/bin/rc
./foo
maia%

current rc does not stop execution.
probably not due to protection problem by kernel.
there must be a bug in rc.

Kenji Arisawa

> 2015/01/25 15:16=E3=80=81arisawa <arisawa@ar.aichi-u.ac.JP> =E3=81=AE=E3=83=A1=E3=83=BC=E3= =83=AB=EF=BC=9A
>
>
> Hello 9fans
>
> my mac has a protection below:
> -bash$ cat foo
> #!/bin/sh
> ./foo
> -bash$ ./foo
> ./foo: fork: Resource temporarily unavailable
> -bash$
>
> on the other hand, Plan 9 does not.
> kernel is protected against such programs, however they are not killed= .
> therefore no new process can be created.
>
> does anyone have idea to fix the problem?
>
> Kenji Arisawa
>
>



--001a11c35ccefc662b050d7804fd-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 25 Jan 2015 09:41:35 -0800 To: 9fans@9fans.net Message-ID: <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> In-Reply-To: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b758d62-ead9-11e9-9d60-3106f5b1d025 On Sat Jan 24 23:16:07 PST 2015, mischief@9.offblast.org wrote: > You would need to implement something like ulimits to fix process > exhaustion, or some kind of rate limit. There are several forms of > resource exhaustion in plan 9. One other that comes to mind is cat > /dev/random prevents other clients from making progress reading > /dev/random, such as cpu. this is the same route as oom killer, which can be depended on to kill exactly the wrong thing at exactly the wrong time. fixing things to be oomkiller-proof tends to be an exercise in wack-a-mole. about tail-calls mentioned elsewhere. rc simple executes the file through a system call and does not inspect its shebang line. so there is no possibility of optimization; rc doesn't know it's an rc script. (and this problem doesn't depend on the executible recursively executing itself being an rc script.) i have eliminated the resrcwait() in the process allocation loop in my kernels. this sounds much worse than it is. the advantage is it breaks the loop and gets the machine running again in a bounded amount of time. the disadvantage is one loses program state. i've found it a win over all. instead of getting paged in the middle of the night, a few days later someone might mention that the machine rebooted. the logs are almost always intact, so debugging the issue isn't too hard /during the middle of the day/. :-) - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: arisawa In-Reply-To: <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> Date: Mon, 26 Jan 2015 20:47:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b7a3588-ead9-11e9-9d60-3106f5b1d025 Hello, I have been playing the following program. I tried on official plan9, 9front, and 9atom. none of them showed messages that come from: sysfatal("fork: %r=E2=80=9D); sysfatal("exec: %r"); I suspect that fork() does not return -1 even if it failed in creating new process. Be ware this program may cause system panic. #include #include #define ERRLEN 256 static int waitfor(int pid, char *msg) { Waitmsg *w; while((w =3D wait()) !=3D nil){ if(w->pid =3D=3D pid){ strncpy(msg, w->msg, ERRMAX); free(w); return 0; } free(w); } return -1; } int run(char *path, char *cmd) { int pid; int status; int n; char *args[32]; char msg[ERRLEN]; n =3D tokenize(cmd, args, 32); args[n] =3D nil; switch(pid =3D fork()) {/* assign =3D */ case -1: sysfatal("fork: %r"); case 0: close(0); exec(path, args); sysfatal("exec: %r"); default: break; } status =3D waitfor(pid, msg); if(status < 0){ werrstr("waitfor: %r"); return -1; } return 0; } void main(int argc, char *argv[]) { char *e; int n; int m =3D 100; char buf[32]; ARGBEGIN{ case 'm': m =3D atoi(ARGF()); break; default: sysfatal("usage"); }ARGEND if(argv[0]) n =3D atoi(argv[0]); else n =3D 0; if(n =3D=3D m) sysfatal("stop"); print("%d\n",n); snprint(buf,sizeof(buf),"8.out -m %d %d",m,n + 1); run("./8.out", buf); exits(nil); } From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 26 Jan 2015 13:46:41 +0100 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b7e933a-ead9-11e9-9d60-3106f5b1d025 yes, look at newproc() in port/proc.c the resrcwait() call in there is what erik was refering to that makes rfork(RFPROC) sleep until a process gets available instead of failing. -- cinap From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 26 Jan 2015 06:13:04 -0800 To: 9fans@9fans.net Message-ID: <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> In-Reply-To: <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b8270a4-ead9-11e9-9d60-3106f5b1d025 On Mon Jan 26 03:43:36 PST 2015, arisawa@ar.aichi-u.ac.jp wrote: > Hello, >=20 > I have been playing the following program. > I tried on official plan9, 9front, and 9atom. > none of them showed messages that come from: > sysfatal("fork: %r=E2=80=9D); > sysfatal("exec: %r"); > I suspect that > fork() > does not return -1 even if it failed in creating new process. exactly. the reason it never returns -1, is that introduces a new failure case in every program running, and testing seems like a huge pain. just testing for "handles fork returning -1" is not good enough, it has to hav= e a reasonable strategy for deailing with no procs. this is hard to get ri= ght. just reboot. i have never been able to recover a system that hit noprocs= . i ended up wasting people's time trying. - erik ps. how may lines like this have you seen. p =3D malloc(n); if(p =3D=3D nil){ ... } is this really useful in most tools? From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: arisawa In-Reply-To: <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> Date: Tue, 27 Jan 2015 09:33:05 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b931f12-ead9-11e9-9d60-3106f5b1d025 Hello, many of resource exhaustion come from careless programming. I would like such processes to be killed immediately. throwing up to broken state might be better. I prefer an option to plan9.ini that enable resrcwait(), because the = call breaks traditional programming style and probably we need more time to have=20 right solution. > 2015/01/26 23:13=E3=80=81erik quanstrom = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 > On Mon Jan 26 03:43:36 PST 2015, arisawa@ar.aichi-u.ac.jp wrote: >> Hello, >>=20 >> I have been playing the following program. >> I tried on official plan9, 9front, and 9atom. >> none of them showed messages that come from: >> sysfatal("fork: %r=E2=80=9D); >> sysfatal("exec: %r"); >> I suspect that >> fork() >> does not return -1 even if it failed in creating new process. >=20 > exactly. >=20 > the reason it never returns -1, is that introduces a new failure case = in > every program running, and testing seems like a huge pain. just > testing for "handles fork returning -1" is not good enough, it has to = have > a reasonable strategy for deailing with no procs. this is hard to get = right. > just reboot. i have never been able to recover a system that hit = noprocs. > i ended up wasting people's time trying. >=20 > - erik >=20 > ps. how may lines like this have you seen. >=20 > p =3D malloc(n); > if(p =3D=3D nil){ > ... > } >=20 > is this really useful in most tools? >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lyndon Nerenberg Content-Type: multipart/signed; boundary="Apple-Mail=_A5631B7F-A6B9-4916-A63C-373079EB4EF6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Mon, 26 Jan 2015 17:30:40 -0800 References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b976e46-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail=_A5631B7F-A6B9-4916-A63C-373079EB4EF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 26, 2015, at 4:33 PM, arisawa wrote: > many of resource exhaustion come from careless programming. > I would like such processes to be killed immediately. > throwing up to broken state might be better. > I prefer an option to plan9.ini that enable resrcwait(), because the = call breaks > traditional programming style and probably we need more time to have=20= > right solution. Not plan9.ini, as that's intel specific. But perhaps a global runtime = switch to turn this on and off (something under /dev/cpu*?), and a = corresponding switch in the /proc/*/ctl interface that would let = individual processes say what's best for them? --Apple-Mail=_A5631B7F-A6B9-4916-A63C-373079EB4EF6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJUxupAAAoJEG8PnXiV/JnUlTUP/Rj1kaGJPbmNbSblggqqLnoj SsOgkZdHwexq9csnNQ3v0W4okrQHFXEBQbgko3hG36x6kWTLVI4zQWl9WKx3UPTz 0xTS2YB/Lf5yh7WySpDIu/ImEYS9ky5EKVAFsv71feD358uUqe93XWvbimKVluSn 3DHKt5RN5JWacOSbs7aKwL8V7+81aezuqPnUSjqERBH+K0hSSBuub8yAh8mWimAd yzCsun5KvJ5O+BVlSbCJvo80iPLC5xTiP1xeJNkqjHSiVyk9XdleWsGKW8lmW+tS nMjEnB6KUoKJSaRj6mkYz4y7suStDD1OfxOaF1tFkvmPaVeqB/5g0uTqS2jzYkxr 4FJ8qkj9yxzWMUvbNjQJYBVccfuSpn0Vn1Z1l+DGGQnmWZZiFmUPymD0AHn8qjDM AjJSu3Iy9YlJshx1k0uC+kfLmws/adl5hRnFPJrBqsrqBAbI/LL+/kcPRYFYFvLQ XKgcIKibOrz3Me/IQjXrvvVop26wfDvbV84khC5XhqLbJEGKcN9alUH19wJSyYEd 9RDvRQANRaySeClImmlr54n8WQriVR6EgtZ2Ei1jnW7hwtlqWooPxzBRhyOXRauR 1bj+iyQIvHZHJwx4ECKLR1QqiKogtBoLe7seu1U9NIZ4Vnfs/BpbWsn360IBcVKN BoFbzI2CBfkXpo+tnXvi =v4Jc -----END PGP SIGNATURE----- --Apple-Mail=_A5631B7F-A6B9-4916-A63C-373079EB4EF6-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 26 Jan 2015 20:13:31 -0800 To: 9fans@9fans.net Message-ID: <528d08272b03179d5df28033fcd6f89b@brasstown.quanstro.net> In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3b9ba290-ead9-11e9-9d60-3106f5b1d025 > > many of resource exhaustion come from careless programming. > > I would like such processes to be killed immediately. > > throwing up to broken state might be better. > > I prefer an option to plan9.ini that enable resrcwait(), because the call breaks > > traditional programming style and probably we need more time to have > > right solution. > > Not plan9.ini, as that's intel specific. But perhaps a global runtime switch to turn this on and off (something under /dev/cpu*?), and a corresponding switch in the /proc/*/ctl interface that would let individual processes say what's best for them? plan9.ini is used by all my machines that pxe boot, though the name is changed to /cfg/pxe/$ea. there are other config mechanisms, but they all rely on bootstrapping variables into #ec. we don't need to invent a new mechanism, even if we do not use plan9.ini. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 26 Jan 2015 20:22:12 -0800 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3ba11194-ead9-11e9-9d60-3106f5b1d025 > many of resource exhaustion come from careless programming. > I would like such processes to be killed immediately. > throwing up to broken state might be better. at the danger of repeating myself, the linux oom killer fills a similar role. its job is to try to identify the process that caused the box to run out of memory and kill it. it's a dasterdly beast that's wrong alot. this isn't because it isn't thoughtfully and well built, it's because the "right" program to kill is not expressed by the system. the oom killer has to guess. i think it will go the same way with fork protection. how do you tell which program is at fault? how do you tell a program forking at high frequency, with short lived children from a fork bomb? (such as a busy web server.) > I prefer an option to plan9.ini that enable resrcwait(), because the call breaks > traditional programming style and probably we need more time to have > right solution. i'm not sure i understand what you mean by "traditional programming style" here as plan 9 exists in part to break unix rules. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: arisawa In-Reply-To: Date: Tue, 27 Jan 2015 16:03:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3baee4f4-ead9-11e9-9d60-3106f5b1d025 Hello, > i think it will go the same way with fork protection. how do you tell = which program > is at fault? how do you tell a program forking at high frequency, = with short lived > children from a fork bomb? (such as a busy web server.) only system administrator knows which processes should keep running. therefore, as Lyndon mentioned, we need a mark =E2=80=9Cdon=E2=80=99t = kill by resource exhaustion=E2=80=9D to processes. if automatic determination is desired, the last stage of /rc/bin/cpurc = and /rc/bin/termrc may be the right place. > i'm not sure i understand what you mean by "traditional programming = style" here > as plan 9 exists in part to break unix rules. as Eric mentioned, we have many many codes such as p =3D malloc(n); if(p =3D=3D nil){ ... } or switch(pid =3D fork()) {/* assign =3D */ case -1: sysfatal("fork: %r"); case 0: ... default: ... } I have beeb writing codes believing those error return is working. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 26 Jan 2015 23:10:29 -0800 From: Ori Bernstein To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-Id: <20150126231029.8c160c2541c3a8ed07c0a62f@eigenstate.org> In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: arisawa Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3bc002c0-ead9-11e9-9d60-3106f5b1d025 Too complex to use, especially since processes come and go regularly. IMO, instead of killing processes, it would be better to keep the hanging behavior in place, but place limits on the resources used by a subsection of the process tree. Think ulimit, but applying to entire process heirarc= hies. On Tue, 27 Jan 2015 16:03:16 +0900 arisawa wrote: > Hello, >=20 > > i think it will go the same way with fork protection. how do you tel= l which program > > is at fault? how do you tell a program forking at high frequency, wi= th short lived > > children from a fork bomb? (such as a busy web server.) >=20 > only system administrator knows which processes should keep running. > therefore, as Lyndon mentioned, we need a mark =E2=80=9Cdon=E2=80=99t k= ill by resource exhaustion=E2=80=9D to processes. > if automatic determination is desired, the last stage of /rc/bin/cpurc = and /rc/bin/termrc may be the right place. >=20 > > i'm not sure i understand what you mean by "traditional programming s= tyle" here > > as plan 9 exists in part to break unix rules. >=20 > as Eric mentioned, we have many many codes such as > p =3D malloc(n); > if(p =3D=3D nil){ > ... > } > or > switch(pid =3D fork()) {/* assign =3D */ > case -1: > sysfatal("fork: %r"); > case 0: > ... > default: > ... > } > I have beeb writing codes believing those error return is working. >=20 >=20 --=20 Ori Bernstein From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6587926e835c37c42821d948684d3961@proxima.alt.za> To: 9fans@9fans.net Date: Tue, 27 Jan 2015 09:12:51 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3bc5b4cc-ead9-11e9-9d60-3106f5b1d025 > I have beeb writing codes believing those error return is working. And so you should. Just because an error condition does not have a clean resolution, does not mean it should not be reported. Or, for that matter, that one should not be assisted in figuring out whether an operation was successful ot not. I don't think Erik is encouraging not reporting error conditions, I hope he's merely pointing out that an unreasonable amount of code doesn't. It's easy to confude cause and effect, in these situations. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5e38f077840a332e8fd10fb77efa5a0b@proxima.alt.za> To: 9fans@9fans.net Date: Tue, 27 Jan 2015 09:15:24 +0200 From: lucio@proxima.alt.za In-Reply-To: <20150126231029.8c160c2541c3a8ed07c0a62f@eigenstate.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3bc98516-ead9-11e9-9d60-3106f5b1d025 > IMO, instead of killing processes, it would be better to keep the hanging > behavior in place, but place limits on the resources used by a subsection > of the process tree. Think ulimit, but applying to entire process heirarchies. Once you introduce limits, you become responsible for applying them wisely. Good luck! Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> Date: Tue, 27 Jan 2015 10:53:55 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7bdcab8437dbff050da012c1 Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3bcec5ee-ead9-11e9-9d60-3106f5b1d025 --047d7bdcab8437dbff050da012c1 Content-Type: text/plain; charset=UTF-8 On 27 January 2015 at 04:22, erik quanstrom wrote: > this isn't because [linux oom killer] isn't thoughtfully and > well built, > it's actually fairly stupid. --047d7bdcab8437dbff050da012c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --047d7bdcab8437dbff050da012c1-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 27 Jan 2015 06:01:12 -0800 To: 9fans@9fans.net Message-ID: <37c4a121a3f17639ccc896b121800139@brasstown.quanstro.net> In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3bd3df66-ead9-11e9-9d60-3106f5b1d025 On Tue Jan 27 02:49:44 PST 2015, charles.forsyth@gmail.com wrote: > On 27 January 2015 at 04:22, erik quanstrom wrote: > > > this isn't because [linux oom killer] isn't thoughtfully and > > well built, > > > > it's actually fairly stupid. the proof that a non-stupid one could be written for me would be in the writing. there are a lot of smart people who care about the matter not doing this. :-) - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 27 Jan 2015 06:05:52 -0800 To: 9fans@9fans.net Message-ID: <8ab632b9ed438c51b66f91487388be80@brasstown.quanstro.net> In-Reply-To: <20150126231029.8c160c2541c3a8ed07c0a62f@eigenstate.org> References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <20150126231029.8c160c2541c3a8ed07c0a62f@eigenstate.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3bd7a68c-ead9-11e9-9d60-3106f5b1d025 > IMO, instead of killing processes, it would be better to keep the hanging > behavior in place, but place limits on the resources used by a subsection > of the process tree. Think ulimit, but applying to entire process heirarchies. doesn't solve the issues of every program needing to deal with failed forks. wouldn't you just love it if a programming error were to put acme in a wierd state? the machine might as well reboot, since you are likely the only user, and the editor is wack. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 27 Jan 2015 06:10:47 -0800 To: 9fans@9fans.net Message-ID: <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3be7ae56-ead9-11e9-9d60-3106f5b1d025 > > i think it will go the same way with fork protection. how do you tell which program > > is at fault? how do you tell a program forking at high frequency, with short lived > > children from a fork bomb? (such as a busy web server.) > > only system administrator knows which processes should keep running. do you wake him up in the middle of the night if this happens to arbitrate? this knowledge of what should be preserved may only be post facto knowledge. "i'll know what to kill off once i see what's running." which assumes a working fork, at least for the administrator. in any event, i'd be interested in code that does do a good job, especially if it passes tests other than the trivial fork bomb, such as many users contributing to exhaustion. > I have beeb writing codes believing those error return is working. do you have tests? did you write a test malloc that will fail when called at every location, and ensure sane behavior? - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: arisawa In-Reply-To: <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> Date: Wed, 28 Jan 2015 09:10:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3cb85df8-ead9-11e9-9d60-3106f5b1d025 we don=E2=80=99t have perfect solution. nevertheless, we must protect system. if we search ideal (or nearly ideal) solution, we should assign limited = resource to each user. however this is a big job, I believe. current plan9 system is running under shared resource model. under this model, it is very hard to protect system from evil-minded = users. keeping this model, we can do something that is, of course, imperfect = (but easy to implement, I believe). for example: (a) select processes that should keep running. (with resrcwait flag, for = example) (b) kill processe that failed to be allocated resource if it doesn=E2=80=99= t has resrcwait flag. this strategy has following problems: (1) innocent processes may be killed. the probability is small if the origin is careless program, but can be = large by evil-mined program. (2) error return from malloc() and fork() are disabled. > 2015/01/27 23:10=E3=80=81erik quanstrom = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 >>> i think it will go the same way with fork protection. how do you = tell which program >>> is at fault? how do you tell a program forking at high frequency, = with short lived >>> children from a fork bomb? (such as a busy web server.) >>=20 >> only system administrator knows which processes should keep running. >=20 > do you wake him up in the middle of the night if this happens to = arbitrate? > this knowledge of what should be preserved may only be post facto = knowledge. > "i'll know what to kill off once i see what's running." which assumes = a working > fork, at least for the administrator. >=20 > in any event, i'd be interested in code that does do a good job, = especially > if it passes tests other than the trivial fork bomb, such as many = users contributing > to exhaustion. >=20 >> I have beeb writing codes believing those error return is working. >=20 > do you have tests? did you write a test malloc that will fail when = called > at every location, and ensure sane behavior? >=20 > - erik >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 27 Jan 2015 19:38:46 -0800 To: 9fans@9fans.net Message-ID: <1fccf1df5e46d5fa5235a40a90a001e3@brasstown.quanstro.net> In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3cc1cfdc-ead9-11e9-9d60-3106f5b1d025 On Tue Jan 27 16:06:49 PST 2015, arisawa@ar.aichi-u.ac.jp wrote: > we don=E2=80=99t have perfect solution. > nevertheless, we must protect system. why does limiting forks "protect the system"? why must be "protect the sy= stem"? and what does that phrase mean in this context? > if we search ideal (or nearly ideal) solution, we should assign limited= resource to each user. > however this is a big job, I believe. >=20 > current plan9 system is running under shared resource model. > under this model, it is very hard to protect system from evil-minded us= ers. plan 9 has no hope against malicious users. they can fill up your disk, = or use all your memory, too. i believe the quote attributed to presotto is "we don't have quotas. ken just yells at anyone who hogs the jukebox." nonetheless, i have experience running multi-user plan 9 systems, and use= rs were not usually the issue. > keeping this model, we can do something that is, of course, imperfect (= but easy to implement, I believe). > for example: > (a) select processes that should keep running. (with resrcwait flag, fo= r example) > (b) kill processe that failed to be allocated resource if it doesn=E2=80= =99t has resrcwait flag. >=20 > this strategy has following problems: > (1) innocent processes may be killed. > the probability is small if the origin is careless program, but can be = large by evil-mined program. > (2) error return from malloc() and fork() are disabled. i think you've turned a problem with bounded recovery time into a situation where the recovery code itself will inadvertently dos attack it= s users. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: arisawa In-Reply-To: <1fccf1df5e46d5fa5235a40a90a001e3@brasstown.quanstro.net> Date: Wed, 28 Jan 2015 15:50:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> <1fccf1df5e46d5fa5235a40a90a001e3@brasstown.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3cd6dbfc-ead9-11e9-9d60-3106f5b1d025 Hello, > nonetheless, i have experience running multi-user plan 9 systems, and = users > were not usually the issue. Eric=E2=80=99s users are all gentleman, all careful people and all = skillful programmers. If your system is served for university students, you will have = different thought. > i think you've turned a problem with bounded recovery time into a > situation where the recovery code itself will inadvertently dos attack = its > users. in case that a process failed in getting resource such as memory or = process,=20 what it should do is very limited: puts out some message and exits. this is right behavior. I have never seen programs that retry malloc() or fork() until succeed. if all processes retry them, the system will get down. this is what I have observed in current plan9 kernel. if any one has cleaner solution, i.e., a solution that never kill = innocent process, I want to see it. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9de1c1a7963c01daa11a516f3117a0c2@proxima.alt.za> To: 9fans@9fans.net Date: Wed, 28 Jan 2015 09:22:08 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3cdb6924-ead9-11e9-9d60-3106f5b1d025 > if any one has cleaner solution, i.e., a solution that never kill innocent process, > I want to see it. I have an almost mathematical certainty that the human factor is by far the greatest contributor to the problem and solving any technical issue would be insignificant by comparison. Like any other form of security, the trade offs are what count. Bloating Plan 9 with feeble attempts to shelter the system against malicious users is, in my opinion, too expensive. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> <1fccf1df5e46d5fa5235a40a90a001e3@brasstown.quanstro.net> From: Quintile Content-Type: text/plain; charset=utf-8 In-Reply-To: Message-Id: <068F2ED1-D863-47CC-A72F-4BFE5A17144C@quintile.net> Date: Wed, 28 Jan 2015 07:48:42 +0000 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3ce3d532-ead9-11e9-9d60-3106f5b1d025 I always thought the best solution for a university system, is to implement t= he fair share scheduler. thus people can use any resource the want on an idl= e machine, but a saturated machine splits its load based on rules. I had this experience when I managed a cray (YMP-El only) and it worked perf= ectly. it did not limit processes per user, but it could. similarly ram use and network bandwidth - though this only works per machine= . personally I like erik's idea, though I would make it a boot option. I would also keep malloc() returning nil on fail, but add emalloc() to libc.= and finally have an environment car that makes emalloc() clas sys fatal)) or= abort() - for debug. Steve > On 28 Jan 2015, at 06:50, arisawa wrote: >=20 > Hello, >=20 >> nonetheless, i have experience running multi-user plan 9 systems, and use= rs >> were not usually the issue. >=20 > Eric=E2=80=99s users are all gentleman, all careful people and all skillfu= l programmers. > If your system is served for university students, you will have different t= hought. >=20 >> i think you've turned a problem with bounded recovery time into a >> situation where the recovery code itself will inadvertently dos attack it= s >> users. >=20 > in case that a process failed in getting resource such as memory or proces= s,=20 > what it should do is very limited: puts out some message and exits. > this is right behavior. > I have never seen programs that retry malloc() or fork() until succeed. > if all processes retry them, the system will get down. > this is what I have observed in current plan9 kernel. >=20 > if any one has cleaner solution, i.e., a solution that never kill innocent= process, > I want to see it. >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1e3ff82b552e438333aa8a996af01cd7@felloff.net> Date: Wed, 28 Jan 2015 14:13:56 +0100 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3ceed112-ead9-11e9-9d60-3106f5b1d025 > in case that a process failed in getting resource such as memory or process, > what it should do is very limited: puts out some message and exits. > this is right behavior. practically, for most simple programs fork error is handled by sysfatal(). but things get more tricky for libthread programs like rio. from thread(2): Errors, notes and resources Thread library functions do not return on failure; if errors occur, the entire program is aborted. in your simple forkloop case, the kernel can break the loop by failing the fork there but if at the same time you draw a window or hit interrupt key while the system ran out of processes, the proccreate() in rio can render your window system unusable. and what about stuff like your multithreaded filservers? factotum? cs? dns? plumber? note that there are interdependencies betweeen these... and there might be multiple instances running (multiple users on a cpu server). the point is, you need to take on the effort of hardening *all* the long running and forking servers against this so they can recover from failing fork, or else you have nothing gained compared to what the kernel does currently. could be done, but its hard to get right and test if you got it right. i'd go for giving the students ther own terminals so they crash ther own machines instead of taking down cpu servers :) -- cinap From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 28 Jan 2015 06:03:13 -0800 To: 9fans@9fans.net Message-ID: <28232d96bbd525fc552e6de76012b300@brasstown.quanstro.net> In-Reply-To: <1e3ff82b552e438333aa8a996af01cd7@felloff.net> References: <1e3ff82b552e438333aa8a996af01cd7@felloff.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3cf32f3c-ead9-11e9-9d60-3106f5b1d025 > > in case that a process failed in getting resource such as memory or process, > > what it should do is very limited: puts out some message and exits. > > this is right behavior. > > practically, for most simple programs fork error is handled by sysfatal(). > but things get more tricky for libthread programs like rio. i'd forgotten the added difficulty with the 32-bit kernels that plan 9 overcommits memory. so in a low-memory situation, a process can be killed by using more stack! - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Wed, 28 Jan 2015 16:09:48 +0200 From: lucio@proxima.alt.za In-Reply-To: <28232d96bbd525fc552e6de76012b300@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3cfbbd32-ead9-11e9-9d60-3106f5b1d025 > i'd forgotten the added difficulty with the 32-bit kernels that plan 9 overcommits > memory. so in a low-memory situation, a process can be killed by using more > stack! I could have sworn I heard otherwise. But things sometimes are not as I think they are. Here, I'm very curious to know why I remember differently. Nemo? Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 28 Jan 2015 06:14:06 -0800 To: 9fans@9fans.net Message-ID: <60504b1e5830333dbea77a0d413a9a06@brasstown.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d0c3874-ead9-11e9-9d60-3106f5b1d025 On Wed Jan 28 06:05:50 PST 2015, lucio@proxima.alt.za wrote: > > i'd forgotten the added difficulty with the 32-bit kernels that plan 9 overcommits > > memory. so in a low-memory situation, a process can be killed by using more > > stack! > > I could have sworn I heard otherwise. But things sometimes are not as I think they are. Here, I'm very curious to know why I remember differently. Nemo? the reason is that each process can have up to 16mb of stack, and this is unaccounted. thus the stack or (seg)?brk can commit to memory that will fault when you touch it. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 28 Jan 2015 06:16:07 -0800 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d12683e-ead9-11e9-9d60-3106f5b1d025 On Tue Jan 27 22:46:22 PST 2015, arisawa@ar.aichi-u.ac.jp wrote: > Hello, >=20 > > nonetheless, i have experience running multi-user plan 9 systems, and= users > > were not usually the issue. >=20 > Eric=E2=80=99s users are all gentleman, all careful people and all skil= lful programmers. > If your system is served for university students, you will have differe= nt thought. erik has students, too. i don't nerf the system for them. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7224032c68ae7df5d34def74c1245cbc@proxima.alt.za> To: 9fans@9fans.net Date: Wed, 28 Jan 2015 16:53:17 +0200 From: lucio@proxima.alt.za In-Reply-To: <60504b1e5830333dbea77a0d413a9a06@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d1a8a6e-ead9-11e9-9d60-3106f5b1d025 > the reason is that each process can have up to 16mb of stack, and this is unaccounted. > thus the stack or (seg)?brk can commit to memory that will fault when you touch it. It's a vague recollection, but the fact that the stack is being overcommitted rings a bell. Thanks, Erik. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <60504b1e5830333dbea77a0d413a9a06@brasstown.quanstro.net> <7224032c68ae7df5d34def74c1245cbc@proxima.alt.za> From: Skip Tavakkolian Date: Wed, 28 Jan 2015 17:02:52 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113997e69c7fd1050db9573e Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d453250-ead9-11e9-9d60-3106f5b1d025 --001a113997e69c7fd1050db9573e Content-Type: text/plain; charset=UTF-8 as someone mentioned, a dedicated real or virtual term (9vx, rpi+9pi) is the right option. is there a reason this might not work for your environment? as for system watchdog, usually an external subsystem is used. i wonder if a cpu (e.g. 9pi) dedicated to monitoring the main cpu's /proc (and perhaps /net) for "abnormal activity" (whatever that is) and killing suspicious procs could work. On Wed Jan 28 2015 at 6:54:01 AM wrote: > > the reason is that each process can have up to 16mb of stack, and this > is unaccounted. > > thus the stack or (seg)?brk can commit to memory that will fault when > you touch it. > > It's a vague recollection, but the fact that the stack is being > overcommitted rings a bell. Thanks, Erik. > > Lucio. > > > --001a113997e69c7fd1050db9573e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable as someone mentioned, a dedicated real or virtual term (9vx, rpi+9pi) is th= e right option. is there a reason this might not work for your environment?=

as for system watchdog, usually an external subsystem is used.= i wonder if a cpu (e.g. 9pi) dedicated to monitoring the main cpu's /p= roc (and perhaps /net) for "abnormal activity" (whatever that is)= and killing suspicious procs could work.

On Wed Jan 28 2015 at 6:54:01 AM <lucio@proxima.alt.za> wrote:
= > the reason is that each process can have up to 16mb of stack, and this= is unaccounted.
> thus the stack or (seg)?brk can commit to memory that will fault when = you touch it.

It's a vague recollection, but the fact that the stack is being
overcommitted rings a bell.=C2=A0 Thanks, Erik.

Lucio.


--001a113997e69c7fd1050db9573e-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> <1fccf1df5e46d5fa5235a40a90a001e3@brasstown.quanstro.net> Date: Wed, 28 Jan 2015 17:28:03 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c37e2e9d7e75050db9b138 Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d4a5cee-ead9-11e9-9d60-3106f5b1d025 --001a11c37e2e9d7e75050db9b138 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28 January 2015 at 06:50, arisawa wrote: > Eric=E2=80=99s users are all gentleman, all careful people and all skillf= ul > programmers. > If your system is served for university students, you will have different > thought. > You might also be running services on it, and it's reasonable that it should manage its resources. It's best to refuse a new load if it won't fit, but that requires a fairly careful system design and works best in closed systems. In a capability system you'd have to present a capability to create a process, and it's easy to ration them. Inside Plan 9, one could have a nested resource allocation scheme for the main things without too much trouble. Memory is a little different because you either under-use (by reserving space) or over-commit, as usually happens with file-system quotas. With memory, I had some success with a hybrid scheme, still not intended for multi-user, but it could be extended to do that. The system accounts in advance for probable demands of things like fork/exec and segment growth (including stack growth). If that preallocation is then not used (eg, because of copy-on-write fork before exec) it is gradually written off. When that fails, the system looks at the most recently created process groups (note groups) and kills them. It differs from the OOM because it doesn't assume that the biggest thing is actually the problem. Instead it looks back through the most recently-started applications since that corresponded to my usage. It's quite common to have long-running components that soak up lots of memory (eg, a cache process or fossil) and they often aren't the ones that caused the problem. Instead I assume something will have started recently that was ill-advised. It would be better to track allocation history across process groups and use that instead but I needed something simple, and it was reasonably effective. For resources such as process (slots), network connections, etc I think a --001a11c37e2e9d7e75050db9b138 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 28 January 2015 at 06:50, arisawa <arisawa@ar.aichi-u.ac.jp&= gt; wrote:
Eric=E2=80=99s users are all gentleman, = all careful people and all skillful programmers.
If your system is served for university students, you will have different t= hought.

You might also be running services = on it, and it's reasonable that it should manage its resources.
It's best to refuse a new load if it won't= fit, but that requires a fairly careful system design and works
best in closed systems. In a capability system you= 9;d have to present a capability to create a process,
and it's easy to ration them. Inside Plan 9, one could have = a nested resource allocation scheme
for the= main things without too much trouble. Memory is a little different because= you either under-use
(by reserving space) = or over-commit, as usually happens with file-system quotas.

With memory, I had so= me success with a hybrid scheme, still not intended for multi-user,
but it could be extended to do that. The system ac= counts in advance for probable demands of
t= hings like fork/exec and segment growth (including stack growth). If that p= reallocation is then not
used (eg, because = of copy-on-write fork before exec) it is gradually written off. When that f= ails,
the system looks at the most recently= created process groups (note groups) and kills them.
It differs from the OOM because it doesn't assume that the b= iggest thing is actually the problem.
Inste= ad it looks back through the most recently-started applications since that = corresponded to my usage.
It's quite co= mmon to have long-running components that
s= oak up lots of memory (eg, a cache process or fossil) and they often aren&#= 39;t the ones that caused
the problem. Inst= ead I assume something will have started recently that was ill-advised. It = would be better
to track allocation history= across process groups and use that instead but I needed something simple,<= /div>
and it was reasonably effective.

For resources su= ch as process (slots), network connections, etc I think a=C2=A0
--001a11c37e2e9d7e75050db9b138-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 28 Jan 2015 18:39:56 +0100 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d55fc34-ead9-11e9-9d60-3106f5b1d025 your mail got cut off after "I think a" -- cinap From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 28 Jan 2015 18:51:49 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c38904372111050dbadd74 Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d5ac548-ead9-11e9-9d60-3106f5b1d025 --001a11c38904372111050dbadd74 Content-Type: text/plain; charset=UTF-8 On 28 January 2015 at 17:39, wrote: > your mail got cut off after "I think a" I'd moved the body of that paragraph into the first paragraph, but that bit had scrolled out of sight. --001a11c38904372111050dbadd74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 28 January 2015 at 17:39, <cinap_lenrek@felloff.net> wrote:
your mail got cut off after &q= uot;I think a"

I'd moved the body of that pa= ragraph into the first paragraph, but that bit had scrolled out of sight.
--001a11c38904372111050dbadd74-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: arisawa In-Reply-To: Date: Thu, 29 Jan 2015 12:57:24 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d5faeb4-ead9-11e9-9d60-3106f5b1d025 Thanks for all. I have looked old source code /sys/src/9/port/proc.c, and found the next = code exists from very old day. lock(&procalloc); for(;;) { if((p =3D procalloc.free) !=3D nil) break; snprint(msg, sizeof msg, "no procs; %s forking", up !=3D nil ? up->text: "kernel"); unlock(&procalloc); resrcwait(msg); lock(&procalloc); } procalloc.free =3D p->qnext; unlock(&procalloc); and rfork(2) says: Rfork will sleep, if necessary, until required process resources = are available. which is also exists from old day. Nevertheless all programs, I believe, in /sys/src are written assuming = rfork() may return -l: switch(rfork(=E2=80=A6.)){ case -1: =E2=80=A6 } Any merit? From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 28 Jan 2015 22:34:22 -0800 To: 9fans@9fans.net Message-ID: <9fcf24ed5349ad1ae3e68b04a2b7cbc3@brasstown.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d6712f8-ead9-11e9-9d60-3106f5b1d025 > Nevertheless all programs, I believe, in /sys/src are written assuming rfork() may return -l: * cifs keepalive thread may not start * ssh2 will malfunction in ssh.c * htmlroff will malfunction * imap4d idle will fail with no warning * upas/scanmail:/^qmail, same issue * page/gs.c will die wierdly etc. so is is incorrect to assume that plan 9 programs even have code to handle fork errors. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 28 Jan 2015 22:42:33 -0800 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d6e267e-ead9-11e9-9d60-3106f5b1d025 > You might also be running services on it, and it's reasonable that it > should manage its resources. It's best to refuse a new load if it > won't fit, but that requires a fairly careful system design and works > best in closed systems. In a capability system you'd have to present > a capability to create a process, and it's easy to ration them. > Inside Plan 9, one could have a nested resource allocation scheme for > the main things without too much trouble. Memory is a little > different because you either under-use (by reserving space) or > over-commit, as usually happens with file-system quotas. > > With memory, I had some success with a hybrid scheme, still not > intended for multi-user, but it could be extended to do that. The > system accounts in advance for probable demands of things like > fork/exec and segment growth (including stack growth). If that > preallocation is then not used (eg, because of copy-on-write fork > before exec) it is gradually written off. When that fails, the system > looks at the most recently created process groups (note groups) and > kills them. It differs from the OOM because it doesn't assume that > the biggest thing is actually the problem. Instead it looks back > through the most recently-started applications since that corresponded > to my usage. It's quite common to have long-running components that > soak up lots of memory (eg, a cache process or fossil) and they often > aren't the ones that caused the problem. Instead I assume something > will have started recently that was ill-advised. It would be better > to track allocation history across process groups and use that instead > but I needed something simple, and it was reasonably effective. > > For resources such as process (slots), network connections, etc I thanks, charles. i hope i haven't overplayed my argument. i am for real solutions to this issue. i'm not for the current solution, or more complicanted variants. how does one account/adjust for long-running, important processes, say forking for a small but important task? perhaps an edf-like scheme predeclaring the expected usage for "important" processes might work? - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: arisawa In-Reply-To: Date: Thu, 29 Jan 2015 17:11:42 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3d75c582-ead9-11e9-9d60-3106f5b1d025 Hi, erik, Thanks a lot! > 2015/01/29 15:42=E3=80=81erik quanstrom = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 > i hope i haven't overplayed my argument. i am for real solutions to = this issue. > i'm not for the current solution, or more complicanted variants.