[9fans] usb serial driver
Hello, Anyone has a driver for FT232R or PL2303HX? Or working on those drivers? Kenji Arisawa
Re: [9fans] usb serial driver
Thank you Gorka, I made a mistake. The usage of 9front is different from that of Bell-labs. It seems FT232R is OK, but PL2303HX has a problem. term% cat /lib/ndb/consoledb group=sys uid=glenda uid=arisawa console=usb3 dev=/dev/eiaU3 openondemand=1 gid=sys console=usb4 dev=/dev/eiaU4 openondemand=1 gid=sys console=usb5 dev=/dev/eiaU5 openondemand=1 gid=sys console=usb6 dev=/dev/eiaU6 openondemand=1 gid=sys console=usb7 dev=/dev/eiaU7 openondemand=1 gid=sys console=usb8 dev=/dev/eiaU8 openondemand=1 gid=sys console=usb9 dev=/dev/eiaU9 openondemand=1 gid=sys console=usb10 dev=/dev/eiaU10 openondemand=1 gid=sys term% cat /dev/usbevent attach 10 067b 2303 00ff term% aux/consolefs term% ls -l /mnt/con* ... --rw-rw-rw- M 190 network network 0 Mar 17 22:09 /mnt/consoles/usb10 ... term% ls /dev/eia* # not listed eiaU10. thus we cannot set the protocols /dev/eia0 /dev/eia0ctl /dev/eia0status /dev/eia1 /dev/eia1ctl /dev/eia1status term% PL2303HX on Bell-labs version has a similar problem. Thank you again. Kenji Arisawa 2014/03/16 17:14、Gorka Guardiola のメール： > Isn't it a variant of the version (almost) supported? There were sone issues > at fast speed, but I believe it is there in the distro. > > > G. > >> On Mar 16, 2014, at 6:40 AM, arisawa wrote: >> >> Hello, >> >> Anyone has a driver for FT232R or PL2303HX? >> Or working on those drivers? >> >> Kenji Arisawa >> >> >
[9fans] fs event
Hello 9fans, linux has inotify freebsd and the friends have kevent and kqueue. I have already released elnfs in Kirara package. the advantage of elnfs is that we need not patch to kernel nor fs. however elnfs does not work cleanly under distributed environment. so, I would like to have fs event in plan9 way. for example: term% echo on >> /srv/cwfs.event# event log on term% cat /srv/cwfs.event # print event queue the implementation will not be difficult but needs patches to fs codes. if anyone interested in, please try. Kenji Arisawa
[9fans] a strange bug in grep
Hello, I found a strange bug in grep. some Japanese runes does not match ‘[^0-9]’. for example ‘ま' (307e) and ‘み’(307f). unicode table from 3040 to 3090 is 3040 3041 ぁ 3042 あ 3043 ぃ 3044 い 3045 ぅ 3046 う 3047 ぇ 3048 え 3049 ぉ 304a お 304b か 304c が 304d き 304e ぎ 304f く 3050 ぐ 3051 け 3052 げ 3053 こ 3054 ご 3055 さ 3056 ざ 3057 し 3058 じ 3059 す 305a ず 305b せ 305c ぜ 305d そ 305e ぞ 305f た 3060 だ 3061 ち 3062 ぢ 3063 っ 3064 つ 3065 づ 3066 て 3067 で 3068 と 3069 ど 306a な 306b に 306c ぬ 306d ね 306e の 306f は 3070 ば 3071 ぱ 3072 ひ 3073 び 3074 ぴ 3075 ふ 3076 ぶ 3077 ぷ 3078 へ 3079 べ 307a ぺ 307b ほ 307c ぼ 307d ぽ 307e ま 307f み 3080 む 3081 め 3082 も 3083 ゃ 3084 や 3085 ゅ 3086 ゆ 3087 ょ 3088 よ 3089 ら 308a り 308b る 308c れ 308d ろ 308e ゎ 308f わ 3090 ゐ I tried some of them. term% cat t3 あ は ば ぱ ひ び ぴ ふ ぶ ぷ へ べ ぺ ほ ぼ ぽ ま み む め も term% grep -v '[^0-9]' t3 ま み term% Kenji Arisawa
Re: [9fans] a strange bug in grep
thanks eric.
that fixed problems of my sample data!
Kenji Arisawa
2014/03/30 8:54、erik quanstrom のメール：
>> Hello,
>>
>> I found a strange bug in grep.
>> some Japanese runes does not match ‘[^0-9]’.
>>
>> for example ‘ま' (307e) and ‘み’(307f).
>>
>
> i can't replicate here with 9atom's fixes to grep.
> with the same t3 file as you've got,
>
> ; wc -l /tmp/t3
>21 /tmp/t3
> ; grep -v '^[0-9]' /tmp/t3 | wc -l
>21
>
> i have some other differences in grep, including -I (same
> as -i, except fold runes), but i think the differences in
> comp.c are what cause the bug. in particular, you really
> need that 0x entry in the tabs.
>
> /n/sources/plan9/sys/src/cmd/grep/comp.c:135,145 - comp.c:135,147
> {
> 0x007f,
> 0x07ff,
> + 0x,
> };
> Rune tab2[] =
> {
> 0x003f,
> 0x0fff,
> + 0x,
> };
>
> Re2
>
> the additional pairs and the correction to the combining case
> here were not accepted to sources, but they allow for large character
> classes generated used by folding. many of the characters are contiguous
> so getting the contiguous case right is important.
>
> /n/sources/plan9/sys/src/cmd/grep/comp.c:215,221 - comp.c:217,223
> Re2
> re2class(char *s)
> {
> - Rune pairs[200+2], *p, *q, ov;
> + Rune pairs[400+2], *p, *q, ov;
> int nc;
> Re2 x;
>
> /n/sources/plan9/sys/src/cmd/grep/comp.c:234,240 - comp.c:236,242
> break;
> p[1] = *p;
> p += 2;
> - if(p >= pairs + nelem(pairs) - 2)
> + if(p == pairs + nelem(pairs) - 2)
> error("class too big");
> s += chartorune(p, s);
> if(*p != '-')
> /n/sources/plan9/sys/src/cmd/grep/comp.c:254,260 - comp.c:256,262
> for(p=pairs+2; *p; p+=2) {
> if(p[0] > p[1])
> continue;
> - if(p[0] > q[1] || p[1] < q[0]) {
> + if(p[0] > q[1]+1 || p[1] < q[0]) {
> q[2] = p[0];
> q[3] = p[1];
> q += 2;
>
> i believe this case is also critical. split the bmp off.
>
> /n/sources/plan9/sys/src/cmd/grep/comp.c:275,281 - comp.c:277,283
> x = re2or(x, rclass(ov, p[0]-1));
> ov = p[1]+1;
> }
> - x = re2or(x, rclass(ov, Runemask));
> + x = re2or(x, rclass(ov, 0x));
> } else {
> x = rclass(p[0], p[1]);
> for(p+=2; *p; p+=2)
>
> - erik
>
Re: [9fans] (no subject)
Hello,
the result below is on one of my machine with GA-H61M-USB3H.
the MB is nice with 9front.
maia% @{rfork n; aux/realemu; aux/vga -p}|grep '^vesa mode'
vesa mode 0x107 1280x1024x8 m8 packed
vesa mode 0x11a 1280x1024x16 r5g6b5 direct
vesa mode 0x11b 1280x1024x32 x8r8g8b8 direct
vesa mode 0x105 1024x768x8 m8 packed
vesa mode 0x117 1024x768x16 r5g6b5 direct
vesa mode 0x118 1024x768x32 x8r8g8b8 direct
vesa mode 0x112 640x480x32 x8r8g8b8 direct
vesa mode 0x114 800x600x16 r5g6b5 direct
vesa mode 0x115 800x600x32 x8r8g8b8 direct
vesa mode 0x101 640x480x8 m8 packed
vesa mode 0x103 800x600x8 m8 packed
vesa mode 0x111 640x480x16 r5g6b5 direct
vesa mode 0x17d 1920x1080x8 m8 packed
vesa mode 0x17e 1920x1080x16 r5g6b5 direct
vesa mode 0x17f 1920x1080x32 x8r8g8b8 direct
maia%
and
maia% echo $vgasize
1920x1080x16
maia%
I have wide screen display with DVI and is quite comfortable.
NOTE that VGA connector cannot live with VESA mode on the MB!
probably MB dependent.
Kenji Arisawa
2014/04/16 7:42、erik quanstrom のメール：
> thanks for the confirmation!
>
> - erik
>
[9fans] 9fat format
Hello, It is curious for me that if 9fat is formatted by disk/format of 9front, then 9atom fails in boot with the error message MBR...PBS2...Bad format or I/O errors (or PBS1) In making 9fat, I applied 9atom’s pbslba, 9load, etc except disk/format: disk/format -b pbslba -d -r 2 /dev/sdC0/9fat 9load 9pc*f plan9.ini I guess PBS2 claims that format of the allocation table is wrong because if the 9fat is formatted by disk/format of 9atom then 9atom can boot up. term% xd -c /dev/sdC0/9fat # formatted using 9front ... 400 f8 ff ff ff 03 00 04 00 05 00 06 00 07 00 \b 00 410 \t 00 \n 00 0b 00 0c 00 \r 00 0e 00 0f 00 10 00 420 11 00 12 00 13 00 14 00 15 00 16 00 17 00 18 00 430 19 00 1a 00 1b 00 1c 00 1d 00 1e 00 1f 0000 440 ! 00 " 00 # 00 $ 00 % 00 & 00 ' 00 ( 00 450 ) 00 * 00 + 00 , 00 - 00 . 00 / 00 0 00 Kenji Arisawa
[9fans] origin of /root
Hello all, have we reliable way to find the origin of /root. local file system? remote file system? Kenji Arisawa
Re: [9fans] dcp - a deep copy script, better than dircp
Hello, I found this mail today. sorry. > Just not to overwrite newer files cpdir does behave this way. 2009/07/20 18:32、c...@gli.cas.cz のメール： > hi, > > i'm quite happy with the 'cpdir' by Kenji Arisawa (thanks, Kenji!) on > sources/contrib/arisawa. > However, your scripty seems fine, too. Could we add a switch to conform with > gnu's cp -au? Just not to overwrite newer files. I don't know there is an > option there in 'tar' (I can't see in in tar(1)). At least we have the 'k' > modifier, which could help. > > Regards, > ++pac. > >
Re: [9fans] 9fat format
it is 100mb thanks 2014/04/17 21:55、erik quanstrom のメール： >> It is curious for me that if 9fat is formatted by disk/format of 9front, >> then 9atom fails in boot with the error message >> MBR...PBS2...Bad format or I/O errors >> (or PBS1) >> In making 9fat, I applied 9atom’s pbslba, 9load, etc except disk/format: >> disk/format -b pbslba -d -r 2 /dev/sdC0/9fat 9load 9pc*f plan9.ini > > 9load and its pbslba doesn't do well with fats >= 100mb. how large > is your 9fat? > > it is recommended that pbsipl, and iplfat be used with 9atom kernels. > > - erik >
[9fans] vx32 compilation for osx
Hello, 9vx for osx is for i386 -bash$ file /usr/local/9vx/9vx.OSX /usr/local/9vx/9vx.OSX: Mach-O executable i386 -bash$ to compile to 64bit, I tried to _make_ on mountain lion. however the compilation fails. -bash$ cd /Users/arisawa/src/vx32-0.12/src -bash$ make make: vx32-gcc: Command not found make: vx32-gcc: Command not found gcc -m32 -c -nostdinc -Ilibvxc/include -g -O3 -MD -std=gnu99 -I. -m80387 -mfp-ret-in-387 -o libvxc/abort.o libvxc/abort.c ... gcc -m32 -c -nostdinc -Ilibvxc/include -g -O3 -MD -std=gnu99 -I. -m80387 -mfp-ret-in-387 -o libvxc/vx32/ffs.o libvxc/vx32/ffs.S libvxc/vx32/ffs.S:44:Unknown pseudo-op: .type libvxc/vx32/ffs.S:44:Rest of line ignored. 1st junk character valued 102 (f). make: *** [libvxc/vx32/ffs.o] Error 1 -bash$ anyone succeed in compiling to 64bit? any suggestion? Kenji Arisawa
Re: [9fans] vx32 compilation for osx
thanks erik. it seems osx marvericks dislike i386…. 2014/05/10 21:40、erik quanstrom のメール： >> 9vx for osx is for i386 > > 9vx depends on 386 features. it does > not extend to amd64. > > - erik >
[9fans] Pegasus-2.7 is released
Hello 9fans, Web server Pegasus-2.7 is released. the change: made the code simpler for quicker response. look http://plan9.aichi-u.ac.jp/netlib/pegasus/ Kenji Arisawa
[9fans] Kirara-2.1 is released
Hello 9fans, full text search engine Kirara-2.1 is released. the changes: (a) Wild card "*" in QE(query expression) is extended to more general form. (b) Wild card "?" in QE(query expression) is supported. Look MAN_KFIND for the syntax. (c) Now indexed words are strings of alphabet, numerics and underscore; and the words that begin with numeric are not excluded any more. Eulopean languages such as German, Spanish, Greek, Cyrillicetc are supported. Japanese runes are also indexed. Look MAN_KFIND for details. The new index size will infrate (few ten percent) from previous version. Data format is kept untouched. (d) Kinder installation instruction for fossil. (e) Kinder installation process. Now we use environment variables $kirara1 and $kirara2, and need not change codes in some rc scripts (kfind1,kfind2,G1,G2,setup) (f) Flexible database organization. (g) Many bug fixes in codes and documents look http://plan9.aichi-u.ac.jp/netlib/kirara/ Kenji Arisawa
Re: [9fans] 2014 hardware overview
look http://plan9.aichi-u.ac.jp/hardware/ 2014/06/29 18:32、Pierre-Jean のメール： > 4) Obvious hardware > > More generally, what do you think is the actual obvious > hardware that one can find to build a file server and a cpu > server for home usage ?
[9fans] Kirara-2.2 is released
Hello 9fans, full text search engine Kirara-2.2 is released. the changes: (a) many bug fixes (b) algorithm for reliable update (c) polished code. look http://plan9.aichi-u.ac.jp/netlib/kirara/ Kenji Arisawa
[9fans] segattach in telnetd
Hello,
we have an example for segattach() in /sys/src/cmd/ip/telnetd.c
void*
share(ulong len)
{
uchar *vastart;
vastart = sbrk(0);
if(vastart == (void*)-1)
return 0;
vastart += 2*1024*1024;
if(segattach(0, "shared", vastart, len) == (void*)-1)
return 0;
return vastart;
}
I think it should be
- if(segattach(0, "shared", vastart, len) == (void*)-1)
+ if((vastart = segattach(0, "shared", vastart, len)) == (void*)-1)
Kenji Arisawa
Re: [9fans] segattach in telnetd
Hello, I think vastart += 2*1024*1024; is weird. if we look /proc/$ip/segment in share(), we will have better solution. but I am not convinced we should apply the solution. because we seldom needs shared segment. I haven’t had any trouble with telnetd. I needed shared segment for special purpose in my program (Pegasus). thanks 2014/09/14 12:17、cinap_len...@felloff.net のメール： > why? segattach() gets an explicit address here and > it should round va down and va+len up as neccesary > to make them page aligned. but the initial passed > range should be covered by the created segment > in any case. > > do you have any trouble with telnet that is fixed > by your change? > > -- > cinap >
Re: [9fans] segattach in telnetd
Hello cinap,
My experiment here.
void
main(int argc, char *argv[])
{ char *ap;
char buf[1];
ARGBEGIN{
default: usage();
}ARGEND
ap = segattach(0,"share",0,1024);
print("%p\n",ap); // error
/* compare */
ap = sbrk(0);
print("sbrk %p\n",ap); // 6cb0
ap += 2*1024*1024;
print("%p\n",ap); // 206cb0
ap = segattach(0, "shared", ap, 1024);
print("%p\n",ap); // 206000
read(0,buf,1);
}
we can find the allocated share memory:
term% cat /proc/612768/segment
Stack defff000 d0001
Text R 1000 60001
Data 6000 70001
Bss 7000 70001
Shared 206000 2070001
term%
note that 0x206cb0 + 0x400 > 0x20700.
if we believe that we have a memory
of range [mp,mp+1024) by executing
mp = share(1024)
then we will fail.
Kenji Arisawa
2014/09/14 12:17、cinap_len...@felloff.net のメール：
> it should round va down and va+len up as neccesary
> to make them page aligned. but the initial passed
> range should be covered by the created segment
> in any case.
Re: [9fans] segattach in telnetd
ooh
that is my halt.
egattach(0,"shared",0,1024);
works fine!
my test
test1(void)
{
char *ap;
ap = segattach(0,"shared",0,1024);
print("%p\n",ap); // deffe000
}
term% cat /proc/917256/segment
Stack defff000 d0001
Text R 1000 60001
Data 6000 70001
Bss 7000 70001
Shareddeffe000 defff0001
term%
that nice.
by the way, is this behavior special to 9front?
Kenji Arisawa
2014/09/14 13:51、cinap_len...@felloff.net のメール：
> it works, you just mistyped "shared" in the first call.
>
> --
> cinap
>
Re: [9fans] shell functions
Hello,
when rc is invoked, rc reconstructs shell variable and shell functions using
files in /env/.
in case of shell functions, rc evaluates whole data in the file.
this feature makes problem if the content is
fn foo {…}; maliciouscommand
I think this problem must be fixed.
Kenji Arisawa
2014/09/27 23:40、Christian Neukirchen のメール：
>
> The problem could be completely avoided if the '{}' were implicit, that
> is, store
>
> fn foo { echo bar }
>
> as
>
> fn#foo=echo bar
>
> (Also, I heard Research Unix v8 sh(1) stored functions in the environment
> as "foo(){ ... }", i.e. without =. So this never clashes with any
> variable. Not sure if that works portably enough for plan9port, though.)
>
> --
> Christian Neukirchenhttp://chneukirchen.org
>
>
Re: [9fans] shell functions
Hi, Richard,
Problems comes from careless CGI handling.
keep the following result in mind
term% 'fn#foo'='fn foo {echo yes}; echo no
'
term% rc
no
term%
today, we have a number of malicious request to our web server.
assume a web server accept a request with a query
query='fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a’
if the query is processed as follows: (the explanation is only for demo)
term% query='fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a'
term% echo $query
fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a
term% ifs='=' a=`{echo -n $query}
term% b=`{echo -n $a(2) | sed 's/%20/ /g; s/%0a/\n/g'}
term% echo -n $b
fn foo {echo yes}; echo no
term% $a(1)=$b
term% rc
no
term%
we can avoid such attacks by putting a prefix (say ‘QS_' as Pegasus does) at
the last stage.
QS_$a(1)=$b
assume the input field is “name”, then some people believe $a(1) is “name”, and
may carelessly
execute for simplicity
$a(1)=$b
and such CGI will work for almost all cases (because they are not malicious).
even if extra command in
fn foo {…}; maliciouscommand
is removed in starting rc, careless handling makes problem.
however it is much different in dangerousness between some environment variable
are destroyed
and arbitrary commands can be executed.
Kenji Arisawa
2014/09/28 18:39、Richard Miller <9f...@hamnavoe.com> のメール：
>> when rc is invoked, rc reconstructs shell variable and shell functions using
>> files in /env/.
>> in case of shell functions, rc evaluates whole data in the file.
>> this feature makes problem if the content is
>> fn foo {…}; maliciouscommand
>
> How would a malicious agent put something into /env? If it's possible,
> how is this different from putting something into $home/bin/rc or
> binding something into /rc/bin ?
>
>
Re: [9fans] shell functions
thanks for all. our conclusion is: worthless to fix. Kenji Arisawa
[9fans] Pjpeg in /sys/lib/mimetype
Hello, It is curious for me that ".jpg" has two entries in /sys/lib/mimetype. term% grep jpeg /sys/lib/mimetype .jfif image jpeg- y .jfif-tbnl image jpeg- y .jpeimage jpeg- y .jpeg image jpeg- y .jpgimage jpeg- y .jpgimage pjpeg - y term% The file is currently consulted by only two applications: mail and httpd. I thought that the file provides conventional way to determine mime type from file suffix. If so, what is the mime type for "foo.jpg"? Kenji arisawa
Re: [9fans] Pjpeg in /sys/lib/mimetype
Hello, I believe the line: .jpgimage pjpeg - y should be removed. I found another curiosity in the file. term% grep compress /sys/lib/mimetype .Z - - compressm .tazapplication x-tar compressm .trzapplication x-tar compressm .z - - compressm .Z - - compressm term% Does this mean that file suffixes are case sensitive in determining the mime type? If so, should files with suffix “.JPG” be renamed to “.jpg” ? Kenji Arisawa 2014/11/14 21:13、arisawa のメール： > Hello, > > It is curious for me that ".jpg" has two entries in /sys/lib/mimetype. > term% grep jpeg /sys/lib/mimetype > .jfif image jpeg- y > .jfif-tbnlimage jpeg- y > .jpe image jpeg- y > .jpeg image jpeg- y > .jpg image jpeg- y > .jpg image pjpeg - y > term% > > The file is currently consulted by only two applications: mail and httpd. > I thought that the file provides conventional way to determine mime type from > file suffix. > If so, what is the mime type for "foo.jpg"? > > Kenji arisawa > >
[9fans] inconsistent comparison?
Hello,
/sys/lib/mimetype is referenced in three files:
/sys/src/cmd/ip/httpd/content.c # for outgoing file
/sys/src/cmd/upas/marshal/marshal.c # for outgoing file
/usr/arisawa/src/upas/vf/vf.c # for incoming file
the codes are as follows.
/sys/src/cmd/ip/httpd/content.c
/sys/src/cmd/ip/httpd/content.c
while((p = strrchr(buf, '.')) != nil){
for(s = suffixes; s; s = s->next){
if(strcmp(p, s->suffix) == 0){
if(s->generic != nil && type == nil)
type = hmkcontent(hc, s->generic,
s->specific, nil);
if(s->encoding != nil && enc == nil)
enc = hmkcontent(hc, s->encoding, nil,
nil);
}
}
*p = 0;
}
/sys/src/cmd/upas/marshal/marshal.c
/* try the mime types file */
if(p != nil){
if(mimetypes == nil)
readmimetypes();
for(c = mimetypes; c != nil && c->ext != nil; c++)
if(strcmp(p, c->ext) == 0){
a->type = c->type;
a->ctype = c;
return a;
}
}
/sys/src/cmd/upas/vf/vf.c
for(m = mtypes; m != nil; m = m->next)
if(cistrcmp(p, m->ext) == 0){
switch(m->class){
case 'm':
case 'y':
return 0;
case 'p':
*p = 0;
rv = badfile(name);
*p = '.';
return rv;
case 'r':
return 2;
}
}
these codes are in 9front but probably same as both official plan9 and 9atom.
note that vf.c uses cistrcmp() but others use strcmp().
this these are intensional?
Re: [9fans] rc: null list in concatenation
example is required. > 2014/11/25 13:24、tre...@india.com のメール： > > Hello everyone. > > I'm curious about the behavior of rc concatenating null strings (brakes > execution on error...). It's a feature, rationally thought-out, or a bug? > > If anyone can tell me the story behind, I'll be grateful. > > trebol. > > P.D. > Sorry for previous mail without subject. > >
Re: [9fans] rc: null list in concatenation
> 2014/11/25 15:56、tre...@india.com のメール：
>
> a = `{ls file}^test; echo 'this part is not executed if file doesn''t exist'
probably your question is as follows:
maia% a = `{ls file}^test; echo 'this part is not executed if file doesn''t
exist'
ls: file: 'file' directory entry not found
rc: null list in concatenation
maia%
on the other hand,
maia% ls file; echo 'this part is not executed if file doesn''t exist'
ls: file: 'file' directory entry not found
this part is not executed if file doesn't exist
maia%
a similar thing is:
maia% (aa bb)=; echo
rc: variable name not singleton!
maia%
perhaps this is a feature.
rc stops execution if there is an error in grammar.
[9fans] bug in rc(1) ?
rc(1) says: rfork [nNeEsfFm] Become a new process group using rfork(flags) where flags is composed of the bitwise OR of the rfork flags specified by the option letters (see fork(2)). If no flags are given, they default to ens. The flags and their meanings are: n is RFNAMEG; N is RFCNAMEG; e is RFENVG; E is RFCENVG; s is RFNOTEG; f is RFFDG; F is RFCFDG; and m is RFNOMNT. this sounds to me rfork is equivalent to rfork ens or am I misunderstanding? Kenji Arisawa
Re: [9fans] bug in rc(1) ?
OK, thanks > 2014/11/29 13:57、minux のメール： > > On Fri, Nov 28, 2014 at 11:42 PM, arisawa wrote: >> rc(1) says: >> >> rfork [nNeEsfFm] >> Become a new process group using rfork(flags) where >> flags is composed of the bitwise OR of the rfork flags >> specified by the option letters (see fork(2)). If no >> flags are given, they default to ens. The flags and >> their meanings are: n is RFNAMEG; N is RFCNAMEG; e is >> RFENVG; E is RFCENVG; s is RFNOTEG; f is RFFDG; F is >> RFCFDG; and m is RFNOMNT. >> >> this sounds to me >>rfork >> is equivalent to >>rfork ens > yes. it also agrees with the source code. > http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/rc/plan9.c:/^execnewpgrp
[9fans] protection against resource exhaustion
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
Re: [9fans] protection against resource exhaustion
thank you, mischief. 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、arisawa のメール： > > > 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 > >
Re: [9fans] protection against resource exhaustion
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”);
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 = wait()) != nil){
if(w->pid == 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 = tokenize(cmd, args, 32);
args[n] = nil;
switch(pid = fork()) {/* assign = */
case -1:
sysfatal("fork: %r");
case 0:
close(0);
exec(path, args);
sysfatal("exec: %r");
default:
break;
}
status = 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 = 100;
char buf[32];
ARGBEGIN{
case 'm': m = atoi(ARGF());
break;
default: sysfatal("usage");
}ARGEND
if(argv[0])
n = atoi(argv[0]);
else
n = 0;
if(n == 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);
}
Re: [9fans] protection against resource exhaustion
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
right solution.
> 2015/01/26 23:13、erik quanstrom のメール：
>
> On Mon Jan 26 03:43:36 PST 2015, aris...@ar.aichi-u.ac.jp wrote:
>> 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”);
>> 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 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.
>
> - erik
>
> ps. how may lines like this have you seen.
>
> p = malloc(n);
> if(p == nil){
> ...
> }
>
> is this really useful in most tools?
>
Re: [9fans] protection against resource exhaustion
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 “don’t kill by resource
exhaustion” 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 = malloc(n);
if(p == nil){
...
}
or
switch(pid = fork()) {/* assign = */
case -1:
sysfatal("fork: %r");
case 0:
...
default:
...
}
I have beeb writing codes believing those error return is working.
Re: [9fans] protection against resource exhaustion
we don’t 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’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、erik quanstrom のメール： > >>> 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 >
Re: [9fans] protection against resource exhaustion
Hello, > nonetheless, i have experience running multi-user plan 9 systems, and users > were not usually the issue. Eric’s 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, 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.
Re: [9fans] protection against resource exhaustion
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 = procalloc.free) != nil)
break;
snprint(msg, sizeof msg, "no procs; %s forking",
up != nil ? up->text: "kernel");
unlock(&procalloc);
resrcwait(msg);
lock(&procalloc);
}
procalloc.free = 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(….)){
case -1:
…
}
Any merit?
Re: [9fans] protection against resource exhaustion
Hi, erik, Thanks a lot! > 2015/01/29 15:42、erik quanstrom のメール： > > 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.
[9fans] Plan9 DNS server
Hello, how to make DNS server that serves for computers on my home network? I tried: ndb/dns -rs 192.168.0.3 is my server’s IP. the name is “maia” and registered /lib/ndb/local as sys=maia dom=maia.local -bash$ nslookup > www.google.com Server: 192.168.0.3 Address:192.168.0.3#53 Non-authoritative answer: Name: www.google.com Address: 216.58.220.228 > maia Server: 192.168.0.3 Address:192.168.0.3#53 ** server can't find maia: NXDOMAIN > maia.local Server: 192.168.0.3 Address:192.168.0.3#53 ** server can't find maia.local: NXDOMAIN > how to enable locally assigned name resolution such as maia? I have many computers on my home network. currently I am registering them to /etc/hosts. but that is a pain. Kenji Arisawa
Re: [9fans] Plan9 DNS server
thanks all. now I have achieved my goal. > 2015/06/22 19:34、lu...@proxima.alt.za のメール： > >> how to enable locally assigned name resolution such as maia? > > The dns man page requires careful reading, but all the details are in > there. I have a pretty complex DNS configuration and it seems to > cause the server to fail more frequently than I like. But the > functionality I need is there, just with one or more weak spots that I > have not been able to identify. > > Lucio. > >
[9fans] ipv6 and ndb/csquery
Hello, I am currently trying ipv6 of Plan9. with a line ip=192.168.0.3 ipv6=fe80::6a05:caff:fe00:fc34 ether=6805ca00fc34 sys=maia in /lib/ndb/local, and executing ipv6on I tried dnsquery and csquery. ii seems dnsquery is OK term% ndb/dnsquery > maia maia.local ip 192.168.0.3 > maia ipv6 maia.local ipv6 fe80::6a05:caff:fe00:fc34 > www.google.com www.google.com ip 173.194.117.212 www.google.com ip 173.194.117.211 www.google.com ip 173.194.117.210 www.google.com ip 173.194.117.208 www.google.com ip 173.194.117.209 > www.google.com ipv6 www.google.com ipv6 2404:6800:4004:80c::1014 > however I don’t understand the behavior of csquery term% ndb/csquery > tcp!maia!* /net/tcp/clone 192.168.0.3!* > tcp!www.google.com!* /net/tcp/clone 173.194.117.210!* /net/tcp/clone 173.194.117.208!* /net/tcp/clone 173.194.117.209!* /net/tcp/clone 173.194.117.211!* /net/tcp/clone 173.194.117.212!* /net/tcp/clone 2404:6800:4004:80c::1014!* > why csquery does not show ipv6 address of maia? Kenji Arisawa
Re: [9fans] ipv6 and ndb/csquery
Thanks. It seems you are right. I have been playing with ipv6 and yet i don’t understand something. What is the rule to select an IP if we allow multiple IPs for a dom? Maybe case by case. But how to select ipv6 in case of telnet? > 2015/07/07 2:01、cinap_len...@felloff.net のメール： > > i dont know for sure but could it be that cs resolves > these local domains thru ndb? and then ignores your > ipv6= attibures in ndb? > > i use ip= attribute in my ndb for both v4 and v6 addresses > and that works fine. > > -- > cinap >
Re: [9fans] ipv6 and ndb/csquery
Thanks cinap, your detailed explanation will be helpful to me and all others. Kenji Arisawa > 2015/07/12 0:37、cinap_len...@felloff.net のメール： > > when you query /net/dns, it differentiates between ip (A) and ipv6 > () records. so querying for "ip" only yields ipv4 addresses and > querying for "ipv6" yields ipv6 addresses only. it shouldnt matter if > you use ip= or ipv6= attribute in ndb for this, as ndb/dns is smart > enogth to check the value of the attribute and figure out if its for > and A or record. > > now ndb/cs is concerned about finding an addresses that is reachable > from your system. i think that is why it reorders the results > based on local ip interfaces. in any case, ndb/cs will query dns > for both ipv4 and ipv6 addresses unless you give it (v4 only flag -4). > > when ndb/cs looks for an address in the network database, it only looks > for the ip= attribute and ignores ipv6= attributes (these are for dns only). > > so if you have no ipv6 connectivity on the lan, but you want to put > ipv6 records in your dns server (to serve to the outside world?), > use the ipv6= attribute in ndb as network database lookups will > ignore the ipv6= stuff. > > when you have both ipv4 and ipv6 connectivity, you can just use > ip= attribute for both v4 and v6 addresses, then network database > lookup will yield both. > > when a domain has multiple ip addresses, dns will randomize the > list of results (for a specific record type). ndb/cs queries dns > for v4 addresses first and v6 addresses last, the (randomized) > v4 addresses appear before the (randomized) v6 addresses > (unless cs did reorder the list as it found the v6 address to be > reachable directly the by a local network interface). > > the results from network database are not randomized (but can be > reordered) by ndb/cs: > > sys=testa ip=89.186.156.12 > ip=2001:470:1f0a:a61::2 > > sys=testb ip=2001:470:1f0a:a61::2 > ip=89.186.156.12 > >> net!testa!* > /net.alt/il/clone 89.186.156.12!*!fasttimeout > /net.alt/il/clone 2001:470:1f0a:a61::2!*!fasttimeout > /net.alt/tcp/clone 89.186.156.12!* > /net.alt/tcp/clone 2001:470:1f0a:a61::2!* > /net.alt/il/clone 89.186.156.12!* > /net.alt/il/clone 2001:470:1f0a:a61::2!* >> net!testb!* > /net.alt/il/clone 2001:470:1f0a:a61::2!*!fasttimeout > /net.alt/il/clone 89.186.156.12!*!fasttimeout > /net.alt/tcp/clone 2001:470:1f0a:a61::2!* > /net.alt/tcp/clone 89.186.156.12!* > /net.alt/il/clone 2001:470:1f0a:a61::2!* > /net.alt/il/clone 89.186.156.12!* > > dial() processes the list from cs in sequential order, unless > you use geoffs parallel dial implementation which connects to > some bounded number of addresses in parallel. > > still the ordering of what cs returns is in most prefered first, > and it is up to cs to define that order. like it *could* decide to > always put ipv6 addresses first, but i think this was not done because > in the labs the v6 network was less reliable than the v4 network? > > -- > cinap >
[9fans] ipv6on bug?
Hello,
in /rc/bin/ipv6on, we have:
mev6=`{ndb/query -f $ndbf sys $sysname ipv6}
if (~ $#sysname 0 || ~ $sysname '')
mev6=`{ndb/query -f $ndbf sys $sysname ip | grep :}
this code is something curious.
bug?
mev6=`{ndb/query -f $ndbf sys $sysname ipv6}
if (~ $#mev6 0 || ~ $mev6 ‘') ### s/sysname/mev6/g
mev6=`{ndb/query -mf $ndbf sys $sysname ip | grep :}###
s/-f/-mf/
Kenji Arisawa
[9fans] dns message
Hello,
running dns with -rs options
I have a lot of messages in /sys/log/dns
term% tail dns
hebe Sep 26 07:17:20 rejecting my ip 192.168.0.6 as local dns server
hebe Sep 26 07:19:34 rejecting my ip 192.168.0.6 as local dns server
hebe Sep 26 07:19:37 rejecting my ip 192.168.0.6 as local dns server
these messages come from:
dblookup.c
addlocaldnsserver(DN *dp, int class, char *ipaddr, int i)
{
...
/* reject our own ip addresses so we don't query ourselves via udp */
if (myaddr(ipaddr))
return;
myaddr(char *addr)
{
char *line, *sp;
char buf[64];
Biobuf *bp;
if(ipcmp(ipaddr, IPnoaddr) == 0)
if(myipaddr(ipaddr, mntpt) < 0)
return -1;
snprint(buf, sizeof buf, "%I", ipaddr);
if (strcmp(addr, buf) == 0) {
dnslog("rejecting my ip %s as local dns server", addr);
return 1;
}
/lib/ndb/local
ipnet=local ip=192.168.0.0 ipmask=255.255.255.0
ipgw=192.168.0.1
smtp=ar
ntp=ntp.jst.mfeed.ad.jp ip
auth=hebe
fs=hebe
# the dns values are advertised by DHCP server
# we assume that dhcpd is running on the same ip. look /cfg/common/cpurc
dns=192.168.0.6
yes my dns is running on 192.168.0.6
any wrong setting in /lib/ndb/local?
if not, I think these warning messages are annoying.
Kenji Arisawa
[9fans] manual qer(8)
Hello, qer(8) says: Runq is often called from cron(8) by an entry such as 0,10,20,30,40,50 * * * * kremvax runq -a /mail/queue /mail/lib/remotemail I think “runq” should be replaced by “upas/runq” Kenji Arisawa
Re: [9fans] manual qer(8)
thanks. anyway, simple “runq” does not work. should be fixed. > 2015/09/26 18:11、Charles Forsyth のメール： > > > On 26 September 2015 at 06:29, arisawa wrote: > I think “runq” should be replaced by “upas/runq” > > mine has /bin/upas/runq -a /mail/queue /mail/lib/remotemail
Re: [9fans] dns message
thank you erik. you are very careful! I didn’t aware that garbage. however removing “ip” does not fix my problem. looking source code I guess: names that are not followed by “=“ are just discarded. I want to know whether this is only to me. erik, thanks again! > 2015/09/27 0:28、erik quanstrom のメール： > >> ipnet=local ip=192.168.0.0 ipmask=255.255.255.0 >> ipgw=192.168.0.1 >> smtp=ar > !>ntp=ntp.jst.mfeed.ad.jp ip >> auth=hebe >> fs=hebe >> # the dns values are advertised by DHCP server >> # we assume that dhcpd is running on the same ip. look /cfg/common/cpurc >> dns=192.168.0.6 > > this is an indication of an issue. > > the ntp line has a trailing ip, which may be confusing the dns client. > > - erik >
[9fans] 9vx on OSX
Hello, does anyone have 9vx that is working on recent osx (Yosemite for example)? mine is weird: when I type “abc”, I have “aabbcc”. Kenji Arisawa
Re: [9fans] 9vx on OSX
Hello, thanks all. > mine is weird: when I type “abc”, I have “aabbcc”. I replaced 9vx (not only 9vx binary but whole set of 9vx package) on Yosemite by the one that is working on Mountain Lion. however the problem is not fixed. probably that is only to me. some differences in environment makes problem. Kenji Arisawa
[9fans] blank line in /lib/ndb/local
Hello, manual ndb(6) says: "Each line starting without white space starts a new tuple. Lines starting with # are comments.” assume we have an entry such as: dom=foo # a blank line follows auth=bar if the blank line contains a white space, then ndb/query dom foo auth will produce dom=foo auth=bar on the other hand, if the blank line is empty, then the command will produce dom=foo Is this a bug or a specification? I want to believe this is a bug. Kenji Arisawa
Re: [9fans] blank line in /lib/ndb/local
hello, your blank line doesn’t have a white space. > 2015/11/10 12:02、erik quanstrom のメール： > > On Mon Nov 9 04:32:24 PST 2015, aris...@ar.aichi-u.ac.jp wrote: >> Hello, >> >> manual ndb(6) says: "Each line starting without white space starts a new >> tuple. Lines starting with # are comments.” >> >> assume we have an entry such as: >> dom=foo >> # a blank line follows >> >> auth=bar >> >> if the blank line contains a white space, then >> ndb/query dom foo auth >> will produce >> dom=foo auth=bar >> on the other hand, if the blank line is empty, then the command will produce >> dom=foo >> >> Is this a bug or a specification? >> I want to believe this is a bug. > > i can't replicate this: > > ; cat a.db > dom=fu > # comment > > auth=bar > ; ndb/query -f a.db dom fu > dom=fu > > > - erik
Re: [9fans] blank line in /lib/ndb/local
yes, your right. the manual says what the code does. however I don’t think it is a good idea to make sense in white spaces within blank line. probably the code does not suppose blank lines within ndb entry. > 2015/11/10 13:05、erik quanstrom のメール： > > On Mon Nov 9 20:03:06 PST 2015, aris...@ar.aichi-u.ac.jp wrote: >> hello, >> >> your blank line doesn’t have a white space. >> >>> 2015/11/10 12:02、erik quanstrom のメール： >>> >>> On Mon Nov 9 04:32:24 PST 2015, aris...@ar.aichi-u.ac.jp wrote: Hello, manual ndb(6) says: "Each line starting without white space starts a new tuple. Lines starting with # are comments.” > > exactly. that's what the manual says. an otherwise blank like with only > whitespace would > fit the definition of a line starting with whitespace, therefore not starting > a new tuple. > > - erik >
[9fans] 9grid again
hello, I am considering a new project that is related to big data. assume we have data on several distributed server. current common approach is: downloading these data from servers to local side and process them. however data is big but program is small. if the data is 1GB order, this approach is practically infeasible. 9grid enables opposite approach: login to servers and process the data there and gather the results. we have all the tools that are necessary to do this as much as 10 years ago. what is lacking is target data. any idea? Kenji Arisawa
[9fans] unmount
Hello 9fans, current kernel allows unmount even if after rfork m. this feature makes sandboxing difficult. can anyone explain this feature is necessary? Kenji Arisawa
Re: [9fans] unmount
I said:
> 2015/12/01 12:24、arisawa のメール：
>
> Hello 9fans,
>
> current kernel allows unmount even if after rfork m.
> this feature makes sandboxing difficult.
> can anyone explain this feature is necessary?
>
> Kenji Arisawa
I make a protection for unmounting after rfork -m and now testing.
my idea is: protecting unmount with a single argument.
it seems the following code is working, however I am not sure this is OK.
any comment welcome.
/sys/src/9/port/sysfile.c:
sysunmount(va_list list)
{
Chan *cmount, *cmounted;
char *name, *old;
name = va_arg(list, char*);
old = va_arg(list, char*);
/* a protection for 'unmount' after 'rfork m'
* we can reject any unmount, however it might not be user
friendly to do so.
* more moderate way might be disallowing
* unmount mntpoint# sigle argument
* it is ideal though: we disalow unmount dirs that are mounted
before rfork m.
* probably we need this protection also in regular kernel
*
* print("name=%s old=%s\n",name,old);
* the output is, e.g,
* name=srv/factorum
* old=/mnt
* -Kenar- */
if(up->pgrp->noattach && (name == nil)){
error(Eperm);
return 0;
}
[9fans] bug in exportfs
Hello,
It seems cpu command is buggy in -P option.
the sources of the problem is in command option -P of exportfs.
I believe /sys/src/cmd/exportfs/pattern.c should be fixed as follows:
int
excludefile(char *path)
{
Reprog **re;
char *p;
if(*(path+1) == 0)
p = "/";
else
p = path+1;
DEBUG(DFD, "checking %s\n", p);
for(re = include; *re != nil; re++){
- if(regexec(*re, p, nil, 0) != 1){
+ if(regexec(*re, p, nil, 0) == 1){
DEBUG(DFD, "excluded+ %s\n", p);
- return -1;
+ return 0;
}
}
for(re = exclude; *re != nil; re++){
if(regexec(*re, p, nil, 0) == 1){
DEBUG(DFD, "excluded- %s\n", p);
return -1;
}
}
return 0;
}
patternfile sample
+ /usr/arisawa
+ /usr/glenda
- /adm
- /sys/log
- /mail
- /usr/.*
Re: [9fans] bug in exportfs
Thanks for your replay.
however I don’t understand the intention of the manual.
real needs in exporting is to export some different directories.
it is impossible to do so under current code.
can anyone show an example that exports two or more directories?
> 2015/12/17 20:40、Peter Hull のメール：
>
> On Wed, Dec 16, 2015 at 11:31 PM, arisawa wrote:
>> It seems cpu command is buggy in -P option.
>> the sources of the problem is in command option -P of exportfs.
>
> I had a look at the manpage for exportfs(4), it says: "For a file to
> be exported, all lines with a prefix + must match and all those with
> prefix - must not match." (http://man.9front.org/4/exportfs)
>
> So isn't the original code correct according to the manpage? If any of
> the regexps in 'include' fail to match, the function returns -1, then
> if any in 'exclude' do match, -1 is returned.
>
>> patternfile sample
>> + /usr/arisawa
>> + /usr/glenda
>> - /adm
>> - /sys/log
>> - /mail
>> - /usr/.*
>>
> Is this sample invalid - no path could match /usr/arisawa and
> /usr/glenda at the same time?
>
> Pete
I said:
> int
> excludefile(char *path)
> {
> Reprog **re;
> char *p;
>
> if(*(path+1) == 0)
> p = "/";
> else
> p = path+1;
>
> DEBUG(DFD, "checking %s\n", p);
> for(re = include; *re != nil; re++){
> - if(regexec(*re, p, nil, 0) != 1){
> + if(regexec(*re, p, nil, 0) == 1){
> DEBUG(DFD, "excluded+ %s\n", p);
> - return -1;
> + return 0;
> }
> }
> for(re = exclude; *re != nil; re++){
> if(regexec(*re, p, nil, 0) == 1){
> DEBUG(DFD, "excluded- %s\n", p);
> return -1;
> }
> }
> return 0;
> }
>
>
> patternfile sample
> + /usr/arisawa
> + /usr/glenda
> - /adm
> - /sys/log
> - /mail
> - /usr/.*
however this code has still a problem.
trailing ‘/‘ is removed in p even if p is a directory.
assume we have users:
/usr/rob
and
/usr/robin
then we cannot export only /usr/rob.
if we wish control this problem, we need tailing ‘/‘ for directory.
then the code should be
excludefile(char *path)
{
Reprog **re;
char *p,*s;
Dir *dir;
if(*(path+1) == 0)
p = "/";
else
p = path+1;
s = p + strlen(p) - 1; /* tail */
dir = dirstat(p);
/* should not be nil */
if((dir->mode)&DMDIR){
/* we have room to append '/'
* look makepath() in exportfs.c */
*++s = '/';
*++s = 0;
}
DEBUG(DFD, "checking %s\n", p);
for(re = include; *re != nil; re++){
if(regexec(*re, p, nil, 0) == 1){
DEBUG(DFD, "excluded+ %s\n", p);
return 0;
}
}
for(re = exclude; *re != nil; re++){
if(regexec(*re, p, nil, 0) == 1){
DEBUG(DFD, "excluded- %s\n", p);
return -1;
}
}
return 0;
}
then patternfile sample become:
+ /usr/arisawa/.*
+ /usr/glenda/.*
- /adm/
- /sys/log/
- /mail/
- /usr/.+
adding tailing ‘/‘ in p makes the pattern file incompatible to existing one.
I don’t know it is better to do so.
Re: [9fans] 9grid again
Hello 9fans. I have started a new 9grid server with some services. Please look http://p9.nyx.link/9grid2/9grid.html for details. This is an experimental service. If you noticed something bad, please inform me. Kenji Arisawa > 2015/11/12 16:30、arisawa のメール： > > hello, > > I am considering a new project that is related to big data. > assume we have data on several distributed server. > current common approach is: > downloading these data from servers to local side and process them. > however data is big but program is small. > if the data is 1GB order, this approach is practically infeasible. > 9grid enables opposite approach: > login to servers and process the data there and gather the results. > we have all the tools that are necessary to do this as much as 10 years ago. > what is lacking is target data. > any idea? > > Kenji Arisawa > >
Re: [9fans] bug in exportfs
No.
The difficulty is in the pattern matching rule.
If we want to export only /usr/glenda, then the pattern matching filer must pass
/usr
/usr/glenda
and must not pass
/usr/
have you get solution?
> 2015/12/22 18:25、Peter Hull のメール：
>
> Mr Arisawa,
> Did you get any answers to this?
> Peter
>
>
> On Thu, 17 Dec 2015 at 13:06 arisawa wrote:
> Thanks for your replay.
> however I don’t understand the intention of the manual.
> real needs in exporting is to export some different directories.
> it is impossible to do so under current code.
> can anyone show an example that exports two or more directories?
>
> > 2015/12/17 20:40、Peter Hull のメール：
> >
> > On Wed, Dec 16, 2015 at 11:31 PM, arisawa wrote:
> >> It seems cpu command is buggy in -P option.
> >> the sources of the problem is in command option -P of exportfs.
> >
> > I had a look at the manpage for exportfs(4), it says: "For a file to
> > be exported, all lines with a prefix + must match and all those with
> > prefix - must not match." (http://man.9front.org/4/exportfs)
> >
> > So isn't the original code correct according to the manpage? If any of
> > the regexps in 'include' fail to match, the function returns -1, then
> > if any in 'exclude' do match, -1 is returned.
> >
> >> patternfile sample
> >> + /usr/arisawa
> >> + /usr/glenda
> >> - /adm
> >> - /sys/log
> >> - /mail
> >> - /usr/.*
> >>
> > Is this sample invalid - no path could match /usr/arisawa and
> > /usr/glenda at the same time?
> >
> > Pete
>
> I said:
>
> > int
> > excludefile(char *path)
> > {
> > Reprog **re;
> > char *p;
> >
> > if(*(path+1) == 0)
> > p = "/";
> > else
> > p = path+1;
> >
> > DEBUG(DFD, "checking %s\n", p);
> > for(re = include; *re != nil; re++){
> > - if(regexec(*re, p, nil, 0) != 1){
> > + if(regexec(*re, p, nil, 0) == 1){
> > DEBUG(DFD, "excluded+ %s\n", p);
> > - return -1;
> > + return 0;
> > }
> > }
> > for(re = exclude; *re != nil; re++){
> > if(regexec(*re, p, nil, 0) == 1){
> > DEBUG(DFD, "excluded- %s\n", p);
> > return -1;
> > }
> > }
> > return 0;
> > }
> >
> >
> > patternfile sample
> > + /usr/arisawa
> > + /usr/glenda
> > - /adm
> > - /sys/log
> > - /mail
> > - /usr/.*
>
> however this code has still a problem.
>
> trailing ‘/‘ is removed in p even if p is a directory.
> assume we have users:
> /usr/rob
> and
> /usr/robin
> then we cannot export only /usr/rob.
> if we wish control this problem, we need tailing ‘/‘ for directory.
> then the code should be
>
> excludefile(char *path)
> {
> Reprog **re;
> char *p,*s;
> Dir *dir;
>
> if(*(path+1) == 0)
> p = "/";
> else
> p = path+1;
>
> s = p + strlen(p) - 1; /* tail */
> dir = dirstat(p);
> /* should not be nil */
> if((dir->mode)&DMDIR){
> /* we have room to append '/'
> * look makepath() in exportfs.c */
> *++s = '/';
> *++s = 0;
> }
>
> DEBUG(DFD, "checking %s\n", p);
> for(re = include; *re != nil; re++){
> if(regexec(*re, p, nil, 0) == 1){
> DEBUG(DFD, "excluded+ %s\n", p);
> return 0;
> }
> }
> for(re = exclude; *re != nil; re++){
> if(regexec(*re, p, nil, 0) == 1){
> DEBUG(DFD, "excluded- %s\n", p);
> return -1;
> }
> }
> return 0;
> }
>
> then patternfile sample become:
>
> + /usr/arisawa/.*
> + /usr/glenda/.*
> - /adm/
> - /sys/log/
> - /mail/
> - /usr/.+
>
> adding tailing ‘/‘ in p makes the pattern file incompatible to existing one.
> I don’t know it is better to do so.
>
>
>
[9fans] bug or feature ? --- ip/ping -6
hello 9fans, I have once posted the message below to 9front mailing list. however looking the origin of the problem, now I think better place is 9fans. == message posted to 9front mailing list == I am feeling weird that ip/ping -6 does not ping to ipv6 address with /lib/ndb/local. # sys=io # ip=192.168.0.5 # ip=2402:6b00:22cd:bf80::5 # hebe% ip/ping -6a io sending 32 64 byte messages 1000 ms apart to icmpv6!io!1 2402:6b00:22cd:bf80::6 -> 192.168.0.5 0: 192.168.0.5 -> 192.168.0.6 rtt 104 µs, avg rtt 104 µs, ttl = 255 1: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 94 µs, ttl = 255 2: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 91 µs, ttl = 255 3: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 89 µs, ttl = 255 this weirdness comes from the order of ip attributes. # sys=io # ip=2402:6b00:22cd:bf80::5 # ip=192.168.0.5 # hebe% ip/ping -6a io sending 32 64 byte messages 1000 ms apart to icmpv6!io!1 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 0: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 102 µs, avg rtt 102 µs, ttl = 255 1: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 88 µs, avg rtt 95 µs, ttl = 255 2: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 84 µs, avg rtt 91 µs, ttl = 255 3: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 104 µs, avg rtt 94 µs, ttl = 255 is this a feature or a bug? Kenji Arisawa
[9fans] bug or feature ? --- ip/ping -6
hello, is the following output of ping reasonable enough? io% 6.ping -an3 hebe sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1 192.168.0.5 -> 192.168.0.6 0: 192.168.0.6 -> 192.168.0.5 rtt 88 µs, avg rtt 88 µs, ttl = 255 1: 192.168.0.6 -> 192.168.0.5 rtt 83 µs, avg rtt 85 µs, ttl = 255 2: 192.168.0.6 -> 192.168.0.5 rtt 80 µs, avg rtt 83 µs, ttl = 255 io% 6.ping -an3 192.168.0.6 sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1 192.168.0.5 -> 192.168.0.6 0: 192.168.0.6 -> 192.168.0.5 rtt 107 µs, avg rtt 107 µs, ttl = 255 1: 192.168.0.6 -> 192.168.0.5 rtt 84 µs, avg rtt 95 µs, ttl = 255 2: 192.168.0.6 -> 192.168.0.5 rtt 95 µs, avg rtt 95 µs, ttl = 255 io% 6.ping -an3 2402:6b00:22cd:bf80::6 sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 103 µs, avg rtt 103 µs, ttl = 255 1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 96 µs, avg rtt 99 µs, ttl = 255 2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 83 µs, avg rtt 94 µs, ttl = 255 io% 6.ping -6an3 hebe sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 101 µs, avg rtt 101 µs, ttl = 255 1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 82 µs, avg rtt 91 µs, ttl = 255 2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 89 µs, avg rtt 90 µs, ttl = 255 io% 6.ping -6an3 192.168.0.6 sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1 192.168.0.5 -> 192.168.0.6 0: 192.168.0.6 -> 192.168.0.5 rtt 90 µs, avg rtt 90 µs, ttl = 255 1: 192.168.0.6 -> 192.168.0.5 rtt 94 µs, avg rtt 92 µs, ttl = 255 2: 192.168.0.6 -> 192.168.0.5 rtt 90 µs, avg rtt 91 µs, ttl = 255 io% 6.ping -6an3 2402:6b00:22cd:bf80::6 sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 101 µs, avg rtt 101 µs, ttl = 255 1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 272 µs, avg rtt 186 µs, ttl = 255 2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 102 µs, avg rtt 158 µs, ttl = 255 code is simplified. io% ls -l --rw-rw-r-- M 327 arisawa arisawa 9942 Dec 30 21:27 ping.c --rw-rw-r-- M 327 arisawa arisawa 10943 Dec 28 15:59 ping.c.orig io% Kenji Arisawa > 2015/12/28 18:04、arisawa のメール： > > hello 9fans, > > I have once posted the message below to 9front mailing list. > however looking the origin of the problem, now I think better place is 9fans. > > == message posted to 9front mailing list == > > I am feeling weird that ip/ping -6 does not ping to ipv6 address with > /lib/ndb/local. > > # sys=io > # ip=192.168.0.5 > # ip=2402:6b00:22cd:bf80::5 > # > hebe% ip/ping -6a io > sending 32 64 byte messages 1000 ms apart to icmpv6!io!1 > 2402:6b00:22cd:bf80::6 -> 192.168.0.5 > 0: 192.168.0.5 -> 192.168.0.6 rtt 104 µs, avg rtt 104 µs, ttl = 255 > 1: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 94 µs, ttl = 255 > 2: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 91 µs, ttl = 255 > 3: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 89 µs, ttl = 255 > > this weirdness comes from the order of ip attributes. > > # sys=io > # ip=2402:6b00:22cd:bf80::5 > # ip=192.168.0.5 > # > hebe% ip/ping -6a io > sending 32 64 byte messages 1000 ms apart to icmpv6!io!1 > 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 > 0: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 102 µs, avg rtt 102 > µs, ttl = 255 > 1: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 88 µs, avg rtt 95 µs, > ttl = 255 > 2: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 84 µs, avg rtt 91 µs, > ttl = 255 > 3: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 104 µs, avg rtt 94 > µs, ttl = 255 > > is this a feature or a bug? > > Kenji Arisawa
Re: [9fans] bug or feature ? --- ip/ping -6
hello, I did nothing about original ping options, so they should work as they have been. I am afraid I have removed too much. the new ping is here. test, please. ping.c Description: Binary data > 2015/12/31 7:43、Kenny Lasse Hoff Levinsen のメール： > > It is not a common factor if you ping broadcast. That is, the local address > is common, the remote is not. > > joushou > >> On 30 Dec 2015, at 20:05, Steve Simon wrote: >> >> I would display the IP address once only, rather on every line; as it is a >> common factor. >> >> -Steve >> >> >>> On 30 Dec 2015, at 15:26, Kurt H Maier wrote: >>> On Wed, Dec 30, 2015 at 03:05:33PM +, Steve Simon wrote: If I where redesigning ping I wouldn't repeat any info that is common on each line - I.e. ip addresses or the column titles: rtt, ave etc. consider plan9's ps(1) which has no column titles. they are described in the man page and are obvious from the context once you have read the man page once. Having said this, I understand that tradition is also a strong guiding principal. -Steve >>> >>> I have no opinion on the labeling, but dropping the IPs from the output >>> would make this tool useless for logging data. >>> >>> khm >> > >
Re: [9fans] need a REAL WORKING iso
hello, I have recently reinstalled 9pi. -rw-r-@ 1 arisawa staff 127695824 1 1 18:38 9pi.img.gz which is downloaded from plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz the img works fine with 8GB sd card (4GB is OK?) I don’t experience your problem. in 9front distribution we can also have 9pif, compile is required though. I have compiled but not tried yet. > /dev/keymap probably /dev/kbmap > 9fs sources works for me Kenji Arisawa > 2016/01/01 20:54、Francois Pussault のメール： > > hello all > > where can i get a iso file for 9front or plan9 for raspberry pi > > > I have the bell-labs./contrib/miller one but it is all > stuck/restricted. even writting to /dev/keymap is impossible... > neither mounting 9fs sources and so on.just unusable at all no inst dir > ... etc so it is just a brick > > I ve allready had one about one year ago that permitted to call inst/textonly > to have a real plan9 station on the RPI fullfeatured and fonctionnal... > > do you have a link that or simillar iso file ? > > thanks > > Cordialement > Francois Pussault > 10 chemin de négo saoumos > apt 202 - bat 2 > 31300 Toulouse > +33 6 17 230 820 +33 5 34 365 269 > fpussa...@contactoffice.fr >
[9fans] a question on csquery
hello, I have the following entries in /lib/ndb/local. sys=io dom=io.local ether=001fd0169891 ip=192.168.0.5 ip=2402:6b00:22cd:bf80::5 sys=hebe dom=hebe.local ether=6805ca0a0bf2 ip=192.168.0.6 ip=2402:6b00:22cd:bf80::6 io% ndb/csquery > tcp!hebe!1 /net/tcp/clone 192.168.0.6!1 /net/tcp/clone 2402:6b00:22cd:bf80::6!1 > tcp!hebe.local!1 /net/tcp/clone 192.168.0.6!1 /net/tcp/clone 2402:6b00:22cd:bf80::6!1 > tcp!io!1 /net/tcp/clone 192.168.0.5!1### does not show both IPs > tcp!io.local!1 /net/tcp/clone 192.168.0.5!1 /net/tcp/clone 2402:6b00:22cd:bf80::5!1 > io% is there any reason that csquery should not show both IPs when address is sysname on that csquery command is executed? Kenji Arisawa
Re: [9fans] a question on csquery
hello erik, did you try ndb/csquery on the machine named dual? > 2016/01/10 1:18、erik quanstrom のメール： > >>> tcp!io.local!1 >> /net/tcp/clone 192.168.0.5!1 >> /net/tcp/clone 2402:6b00:22cd:bf80::5!1 >>> >> io% >> >> is there any reason that csquery should not show both IPs >> when address is sysname on that csquery command is executed? > > perhaps a dns failure? i am not seeing this > > for this entry > ip=10.1.1.19 ip=2402:6b00:22cd:bf80::6 sys=dual dom=dual.quanstro.net > i get > >> tcp!dual!1 > /net/tcp/clone 10.1.1.19!1 > /net/tcp/clone 2402:6b00:22cd:bf80::6!1 >> tcp!dual.quanstro.net!1 > /net/tcp/clone 10.1.1.19!1 > /net/tcp/clone 2402:6b00:22cd:bf80::6!1 > > - erik >
Re: [9fans] a question on csquery
hello erik, > there is no machine named "dual". it was just a set of ndb entries. > i tried the same experiment with a machine i have, and got the same > result. > > - erik > hmmm… then it seems that problem is only to me. thanks for your experiments!
[9fans] WiFi for Plan9
Hello 9fans, I have installed plan9(9front) to EeePC 901 so that I can test IPv6 from wan side. aux/wpa works fine. however I don’t know how to switch to other essid. I tryed: Kill wpa ip/ipconfig unbind Kill ipconfig but these operations doesn’t help go back to starting point. now I reboot and reconnect to other essid. anyone knows better way? Kenji Arisawa
Re: [9fans] WiFi for Plan9
thanks cinap, your advice resolved my problem. aux/wpa is pretty wise! > 2016/01/31 6:37、cinap_len...@felloff.net のメール： > > aux/wpa doesnt need to be restarted really. it uses factotum to derive > the psk using the current essid read from the wifi drivers ifstats file. > so to switch essid's you can just set essid with echo essid > > /net/etherX/clone > or the ctl file. (note, you can read the ifstats file to see the list of ap's > it found). > > if you run a key prompter like aux/fgui, it should prompt for the > password. otherwise you need to have the key in factotum for that essid like: > > key proto=wpapsk role=client essid=XXX !password=YYY > > -- > cinap >
[9fans] bell-labs wiki page
hello 9fans, bell-labs wiki page is down. both http://www.cs.bell-labs.com/wiki/plan9//plan_9_wiki/ and http://www.cs.bell-labs.com/wiki/plan9/plan_9_wiki/ says: Object not found is there any mirror of that wiki? Kenji Arisawa
Re: [9fans] bell-labs wiki page
many thanks. > 2016/02/10 10:45、R. Lucas van Ryn のメール： > > On Wed, Feb 10, 2016 at 10:40:21AM +0900, arisawa wrote: >> bell-labs wiki page is down. >> >> is there any mirror of that wiki? > > There is http://9p.io/wiki/plan9/plan_9_wiki/ >
Re: [9fans] bell-labs wiki page
Hello 9fans, I also have constructed mirror page of Plan 9 Wiki just now. please try. http://p9.nyx.link/wiki/plan_9_wiki/ > 2016/02/10 12:32、arisawa のメール： > > many thanks. > >> 2016/02/10 10:45、R. Lucas van Ryn のメール： >> >> On Wed, Feb 10, 2016 at 10:40:21AM +0900, arisawa wrote: >>> bell-labs wiki page is down. >>> >>> is there any mirror of that wiki? >> >> There is http://9p.io/wiki/plan9/plan_9_wiki/ >> > >
Re: [9fans] bug in exportfs
Hello, > 2016/02/15 7:57、Charles Forsyth のメール： > > > On 14 February 2016 at 16:38, wrote: > i could imagine the filtering being usefull when cpu'ing to foreign machines, > as a server can easily compromize your system when cpu exports your whole > local namespace > > You'd still be better off using a custom nsfile to control it, running that > cpu in > a more restricted name space from the start, so leaks are impossible. filtering of exportfs is handy if it works well. for example, assume we want to exclude all files of name that begins with “.”, then it is probably difficult to do so using only nsfile. the “+” filtering is almost useless. it will not be difficult to rewrite the current code so that we have better matching rule. (I think ordering of pattern sequence should be used in evaluation.) however the change may break something others. (but I doubt the “+” filtering is really used)
[9fans] mirror of sources of bell-labs
Hello 9fans, I added mirror page of sources of bell-labs. look http://p9.nyx.link/sources I am afraid the page has a problem with copyright or something else. if so, please inform me. I will remove them if necessary. Kenji Arisawa
[9fans] 9pfuse and u9fs
Hello 9fans, my 9pfuse on macbook works fine in communicating plan9 file server. however mounting u9fs fails with the message: -bash$ 9pfuse /srv/mmac /n/mmac 9pfuse: fsmount: fid unknown or out of range -bash$ how to understand this message? does anyone succeed in mounting u9fs? it would be great if 9pfuse can mount u9fs Kenji Arisawa
Re: [9fans] 9pfuse and u9fs
thanks for your reply. the server mmac is mac and mountable from plan9 using 9fs. auth method is set to p9any in u9fs setting. In the experiment, I once (and only once) requested password -bash$ 9fs mmac !adding key: role=client proto=p9sk1 dom=mmac user[arisawa]: password: ! authdial: Connection refused -bash$ I don’t know why I am refused. the password is probably registered to factotum -bash$ 9 mount /srv/factotum /mnt/factotum -bash$ cat /mnt/factotum/ctl key dom=mmac proto=p9sk1 role=client user=arisawa !password? -bash$ however -bash$ 9pfuse /srv/mmac /n/mmac 9pfuse: fsmount: fid unknown or out of range -bash$ has anyone experienced similar problem? > 2016/02/16 20:51、David Arroyo のメール： > > I have definitely used 9pfuse to mount a u9fs file server before. What auth > method did you choose for u9fs? > > David > > On February 16, 2016 5:20:51 AM EST, arisawa wrote: > Hello 9fans, > > my 9pfuse on macbook works fine in communicating plan9 file server. > however mounting u9fs fails with the message: > -bash$ 9pfuse /srv/mmac /n/mmac > 9pfuse: fsmount: fid unknown or out of range > -bash$ > how to understand this message? > does anyone succeed in mounting u9fs? > > it would be great if 9pfuse can mount u9fs > > Kenji Arisawa > > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.
[9fans] file descriptor leak
Hello,
I have observed warning messages from dns server:
dns 30792: warning process exceeded 100 file descriptors
dns 30888: warning process exceeded 200 file descriptors
…
probably the file descriptor leak comes from dnresolve.c
udpquery(Query *qp, char *mntpt, int depth, int patient, int inns)
{
…
msg = system(open("/dev/null", ORDWR), "outside");
…
}
char *
system(int fd, char *cmd)
{
int pid, p, i;
static Waitmsg msg;
if((pid = fork()) == -1)
sysfatal("fork failed: %r");
else if(pid == 0){
dup(fd, 0);
close(fd);
for (i = 3; i < 200; i++)
close(i); /* don't leak fds */
execl("/bin/rc", "rc", "-c", cmd, nil);
sysfatal("exec rc: %r");
}
for(p = waitpid(); p >= 0; p = waitpid())
if(p == pid)
return msg.msg;
return "lost child";
}
fd is lost if pid > 0
my server is running on 9front. however both 9atom and bell-labs use same
routine.
Kenji Arisawa
Re: [9fans] file descriptor leak
the logic (code? usage?) of system(int fd, char *cmd) is ugly. thanks for fixing, cinap. charies may be speaking right point, because the dns server is running only for my home use. only my family uses the dns service. my home network is very simple.I have never used /net.alt for that. the dns had been running on file server and sometimes (once a month or so) failed into trouble. a few weeks ago, I separated it from file server so that I can see the trouble really comes from dns. the contents of /proc/N/fs are shown below. it seems /dev/null is not the criminal as charies suggested. how to find fd leakage? thanks in advance io% ps|grep dns arisawa 2480:00 0:00 348K Awaitdns arisawa 2490:00 0:0014584K Preaddns arisawa 2500:12 0:1214576K Preaddns io% cat /proc/^(248 249 250)^/fd /usr/arisawa 0 r M8 (0005 0 00) 81921 /dev/cons 1 w c0 (0002 0 00) 01 #c/cons 2 w c0 (0002 0 00) 0 193 #c/cons 3 r c0 (000f 0 00) 04 /dev/random 4 w M 22 (ce7e 54050 40) 8192 1098023 /sys/log/dns 5 r c0 (0001 0 00) 0 6873616 /dev/bintime 6 r M 22 (929e 3098 00) 819210949 /lib/ndb/local 7 r M 22 (929b 47 00) 819210242 /lib/ndb/common 8 r I0 (0004 3 00) 0 127 /net/ndb 9 rw |0 (0fc1 0 00) 65536 3954 #|/data 11 w s0 (0009 0 00) 02 #s/dns /usr/arisawa 0 r M8 (0005 0 00) 81921 /dev/cons 1 w c0 (0002 0 00) 01 #c/cons 2 w c0 (0002 0 00) 0 193 #c/cons 3 r c0 (000f 0 00) 04 /dev/random 4 w M 22 (ce7e 54050 40) 8192 1098023 /sys/log/dns 5 r c0 (0001 0 00) 0 6873816 /dev/bintime 6 r M 22 (929e 3098 00) 819210949 /lib/ndb/local 7 r M 22 (929b 47 00) 819210242 /lib/ndb/common 8 r I0 (0004 3 00) 0 127 /net/ndb 9 rw |0 (0fc1 0 00) 65536 3954 #|/data 11 w s0 (0009 0 00) 02 #s/dns 12 rw I0 (0002002d 0 00) 0 3362 /net/udp/1/data /usr/arisawa 0 r M8 (0005 0 00) 81921 /dev/cons 1 w c0 (0002 0 00) 01 #c/cons 2 w c0 (0002 0 00) 0 193 #c/cons 3 r c0 (000f 0 00) 04 /dev/random 4 w M 22 (ce7e 54050 40) 8192 1098023 /sys/log/dns 5 r c0 (0001 0 00) 0 6873824 /dev/bintime 6 r M 22 (929e 3098 00) 819210949 /lib/ndb/local 7 r M 22 (929b 47 00) 819210242 /lib/ndb/common 8 r I0 (0004 3 00) 0 127 /net/ndb 9 rw |0 (0fc1 0 00) 65536 3954 #|/data 11 w s0 (0009 0 00) 02 #s/dns 12 rw I0 (0002002d 0 00) 0 3362 /net/udp/1/data io% > 2016/02/17 7:24、Charles Forsyth のメール： > > > On 16 February 2016 at 15:52, arisawa wrote: > > I have observed warning messages from dns server: > dns 30792: warning process exceeded 100 file descriptors > dns 30888: warning process exceeded 200 file descriptors > > It's worth noting that this message doesn't necessarily mean you've got a > file descriptor leak. > It might, but at the start it just means that a process (or process group > sharing a file descriptor group) has many file descriptors open. > That could happen if a server with many clients has a file descriptor per > client and then client requests open some more. > > ndb/dns in particular will try user-level requests in parallel, and those in > turn can lead to several concurrent > queries to various name servers at a given level (root itself has 13). Web > browser clients will fetch page > elements concurrently. That's why it's useful to check the /proc/N/fd file to > try to see what they are. > (Not just for ndb/dns, but for other applications that provoke the message.) > Arguably, if you're using the system in a real, Internet-facing application, > the warning message might > be obsolete, compared to the time when even 100 clients was a big network.
Re: [9fans] rtl8169 gbe slow
hello, rtl8169 is popular in cheap MB, so it is installed in my many MBs. however, cat /dev/kmesg claims: rtl8169: oui 0x732 phyno 1, macv = 0x3c00 phyv = 0x0002 #l0: rtl8169: 100Mbps port 0xD000 irq 10: 001fd0169891 the “100Mbps" in the message is correct or not? I also feel rtl8169 is slow, so I replace on-board rtl8169 by intel’s card if possible. > 2016/02/18 22:22、erik quanstrom のメール： > > the 8169 driver is pretty fast. I've measured it at more than 500mbps. > it sounds like something else is misbehaving. what does > /dev/irqstat say. I bet something is stuck. > > - erik > > > On Feb 18, 2016 3:30 AM, tlaro...@polynum.com wrote: >> >> Hello, >> >> I have finally managed to install plan9 on my new workstation. >> >> By putting back the keyboard on the PS2 connector, I have solved some >> unfelicities (with the USB->legacy emulation, the keyboard switched >> every other typing to UPPERCASE...). >> >> The mouse, still USB connected and hence "emulated" by the BIOS, >> does not react very gracefully but I will see if I can play with >> the acceleration and the resolution to have a better terminal. (Or >> if I manage to find a long enough cable to have a COM slot back since >> there is the bare connector on the motherboard; in this case I will go >> back to a com mouse and will be able to probe USB for other >> devices---external disks.) >> >> One thing is inconvenient: I have a rtl8169 gbe pci-e ether card, but >> when testing the compilation of kerTeX (it has been fixed: it works for >> the last release; rio to come for METAFONT), the throughput with hget is >> abysmal: 30kB/s... The disk is not a fault, reacting well enough (I have >> plenty of RAM and the blocks cache for fossil is set to 3000---it could >> be obviously higher). >> >> Setting the mtu to jumbo packet does not help. >> >> Is there something to tune or is it simply that the chip is not well >> supported? >> >> TIA >> -- >> Thierry Laronde >> http://www.kergis.com/ >> http://www.arts-po.fr/ >> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C >> >>
Re: [9fans] 9Cloud Source
where is patch on http://9p.io/ ? there are your patch on sources grid% ls -l /n/sources/patch/syscall-* --rw-rw-r-- M 105 fst sys 35842 Mar 17 09:52 /n/sources/patch/syscall-exportfs/chan.c --rw-rw-r-- M 105 fst sys 35357 Mar 17 09:52 /n/sources/patch/syscall-exportfs/chan.c.orig --rw-rw-rw- M 105 fst sys27 Mar 17 09:51 /n/sources/patch/syscall-exportfs/email --rw-rw-r-- M 105 fst sys 25215 Mar 17 09:52 /n/sources/patch/syscall-exportfs/exportfs.c --rw-rw-r-- M 105 fst sys 306 Mar 17 09:52 /n/sources/patch/syscall-exportfs/files --rw-rw-r-- M 105 fst sys 20634 Mar 17 09:51 /n/sources/patch/syscall-exportfs/libc.h --rw-rw-r-- M 105 fst sys 20598 Mar 17 09:51 /n/sources/patch/syscall-exportfs/libc.h.orig --rw-rw-r-- M 105 fst sys 4594 Mar 17 09:52 /n/sources/patch/syscall-exportfs/mkfile --rw-rw-r-- M 105 fst sys 4580 Mar 17 09:52 /n/sources/patch/syscall-exportfs/mkfile.orig --rw-rw-r-- M 105 fst sys 0 Mar 17 09:51 /n/sources/patch/syscall-exportfs/notes --rw-rw-r-- M 105 fst sys 23608 Mar 17 09:52 /n/sources/patch/syscall-exportfs/portdat.h --rw-rw-r-- M 105 fst sys 23541 Mar 17 09:52 /n/sources/patch/syscall-exportfs/portdat.h.orig --rw-rw-r-- M 105 fst sys 11501 Mar 17 09:52 /n/sources/patch/syscall-exportfs/portfns.h --rw-rw-r-- M 105 fst sys 11440 Mar 17 09:52 /n/sources/patch/syscall-exportfs/portfns.h.orig --rw-rw-r-- M 105 fst sys 229 Mar 17 09:53 /n/sources/patch/syscall-exportfs/readme --rw-rw-r-- M 105 fst sys 986 Mar 17 09:52 /n/sources/patch/syscall-exportfs/sys.h --rw-rw-r-- M 105 fst sys 967 Mar 17 09:52 /n/sources/patch/syscall-exportfs/sys.h.orig --rw-rw-r-- M 105 fst sys 8853 Mar 17 09:52 /n/sources/patch/syscall-exportfs/syscallfmt.c --rw-rw-r-- M 105 fst sys 8853 Mar 17 09:52 /n/sources/patch/syscall-exportfs/syscallfmt.c.orig --rw-rw-r-- M 105 fst sys 3403 Mar 17 09:52 /n/sources/patch/syscall-exportfs/systab.h --rw-rw-r-- M 105 fst sys 3341 Mar 17 09:52 /n/sources/patch/syscall-exportfs/systab.h.orig grid% > 2016/03/17 10:16、Skip Tavakkolian のメール： > > I couldn't find it on 9p.io, so I'm not sure what happened. I recall that I > screwed up the first two attempts and had to ask David to clean them up for > me. > > Anyhow, I submitted the patch to Labs' sources a few minutes ago: > /n/sources/patch/syscall-exportfs > > > On Wed, Mar 16, 2016 at 5:18 PM Skip Tavakkolian > wrote: > i mean "syscall-exportfs" > > > On Wed, Mar 16, 2016 at 5:10 PM Skip Tavakkolian > wrote: > i submitted the patch to 9p.io some time ago; it was under "syscall-exprotfs". > > > On Wed, Mar 16, 2016 at 4:16 PM hiro <23h...@gmail.com> wrote: > Hello Skip, is there a way I could receive the patch for export? > > On 7/15/15, Skip Tavakkolian <9...@9netics.com> wrote: > > assuming you mean 9PCloud (otherwise ignore this): > > > > i plan to put the 9P javascript sources on github or bitbucket. you > > can view the sources using the debugger in chrome. they're all > > dual-licensed (MIT and GPLv2). i also plan to make a simple version > > of the namespace "janitor" (brucee coined the term) that uses factotum > > handle auth. it will be in the same source repo. > > > > the backend uses a custom Plan 9 cpu that includes the "export" > > (exportfs) system call. the patch for export was submitted to all > > fronts, popular or otherwise (Labs, 9p.io, 9atom, 9front). > > > >> Hi guys, > >> > >> Was wondering if the source of 9Cloud was available for perusal? Just > >> logged in, looks great! > >> > >> Many thanks! > >> > >> Shane. > > > > > > >
[9fans] cpu command latency
Hello,
some people say that cpu command latency will be so big that world wide grid
computing using cpu command will be useless because of the latency.
unfortunately I don’t have experimental data.
it seems bell-labs grid servers are now closed.
latency data between japan and other country will be enough.
I want to have those times:
for(i in 1 2 3){
time cpu -h HOST -k ‘dom=DOM’ -c pwd
sleep 3
}
they are cache sensitive. therefore, we need to restart the plan9 terminal in
the experiment.
if there are open grid servers for 9fans, I would do myself. let me know if you
know, please.
I am also happy if someone give me data by accessing my grid server.
then the HOST is grid.nyx.link and the DOM is outside.plan9.bell-labs.com and
need your bell-labs key in factotum.
thanks in advance.
Kenji Arisawa
Re: [9fans] cpu command latency
thanks charles for your quick response.
the times below are mount latency just after rebooting.
the first is much larger than others.
0.00u 0.00s 3.73r9fs sources
0.00u 0.00s 0.71r9fs sources
0.00u 0.00s 0.21r9fs sources
with the script below:
for(i in 1 2 3){
time 9fs $host
unmount /n/$host
sleep 3
}
}
probably cpu command latency will show similar behavior with much more time.
Kenji Arisawa
Re: [9fans] cpu command latency
Hello, we can measure the latency that comes from network connection by executing simple program such as telnet or something others to the port 8006 of grid.nyx.link. the content is: #!/bin/rc cat $net/local cat $net/remote yes the DNS may make a problem in IPv4/IPv6 mixed environment. my server supports both IPs. the cpu command will select IPv4. the command does not have “-6” option. If we want to connect by IPv6, literal IP address is required in the argument of the command. Kenji Arisawa > In my experience, it's almost unfailingly the DNS that slows down > establishing an Internet session of any type. > > Lucio. > 2016/05/12 0:23、Kenny Lasse Hoff Levinsen のメール： > > Well, based on the 9fs test that was posted, I'd think dial is being awfully > slow. > > Maybe try something simpler? aux/listen1 echo hello and a simple network > connection? > > Best regards, > Kenny Levinsen > > On 11. maj 2016, at 16.13, Charles Forsyth wrote: > >> >> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen >> wrote: >> Delete the channel from /srv in the loop to test a full remote mount dance, >> including the initial dial. It shouldn't take 3s to dial, though. >> >> There's something initially slow in connecting to grid.nyx.link with cpu, >> and setting up, but once there it's fine.
Re: [9fans] cpu command latency
Hello,
> 2016/05/11 22:44、Kenny Lasse Hoff Levinsen のメール：
>
> Delete the channel from /srv in the loop to test a full remote mount dance,
> including the initial dial. It shouldn't take 3s to dial, though.
thanks for the advice.
I retried
for(i in 1 2 3){
time 9fs $host
#unmount /n/$host
rm /srv/$host
sleep 3
}
term% try -m sources outside.plan9.bell-labs.com arisawa
post...
0.00u 0.01s 1.31r9fs sources
post...
0.00u 0.03s 0.69r9fs sources
post...
0.00u 0.00s 0.58r9fs sources
term%
term% try -m sources outside.plan9.bell-labs.com arisawa
post...
0.00u 0.01s 1.30r9fs sources
post...
0.00u 0.01s 0.60r9fs sources
post...
0.00u 0.01s 0.55r9fs sources
term%
for(i in 1 2 3){
time 9fs $host
unmount /n/$host
#rm /srv/$host
sleep 3
}
term% try -m sources outside.plan9.bell-labs.com arisawa
post...
0.00u 0.00s 1.25r9fs sources
0.00u 0.01s 0.18r9fs sources
0.00u 0.00s 0.19r9fs sources
term%
term% try -m sources outside.plan9.bell-labs.com arisawa
post...
0.00u 0.00s 1.26r9fs sources
0.00u 0.00s 0.19r9fs sources
0.00u 0.01s 0.20r9fs sources
term%
the values reported yesterday are:
0.00u 0.00s 3.73r9fs sources
0.00u 0.00s 0.71r9fs sources
0.00u 0.00s 0.21r9fs sources
which shows mount latency depends much on the network condition.
Re: [9fans] cpu command latency
thanks skip for the information.
> 2016/05/12 7:39、Skip Tavakkolian のメール：
> FYI, from Seattle I see about 8 seconds to establish but as Charles noted,
> it's reasonably fast after that.
I am glad if you can show me the raw data measured by
for(i in 1 2 3){
time cpu -h HOST -k ‘dom=DOM’ -c pwd
sleep 3
}
thanks in advance.
Kenji Arisawa
Re: [9fans] cpu command latency
Hello
this is a partial report of cpu command latency.
we have code below in rexcall() of cpu.c
na = netmkaddr(host, 0, service);
//na = netmkaddr(host, “tcp”, service);//DBG
syslog(0,"cpu","rexcall:netmkaddr %lld μsec;
%s",(nsec()-t0)/1000,na);//DBG
procsetname("dialing %s", na);
syslog(0,"cpu","rexcall:dialing %lld μsec;
%s",(nsec()-t0)/1000,na);//DBG
if((*fd = dial(na, 0, devdir, 0)) < 0)
return "can't dial";
syslog(0,"cpu","rexcall:dial %lld μsec",(nsec()-t0)/1000);//DBG
lines with “DBG” are code added for measurement.
looking the result I found dial() takes as much as on second in my home network!
vbt May 14 21:27:52 rexcall:netmkaddr 122 μsec; net!io!ncpu
vbt May 14 21:27:52 rexcall:dialing 592 μsec; net!io!ncpu
vbt May 14 21:27:53 rexcall:dial 1161556 μsec
vbt May 14 21:27:57 rexcall:netmkaddr 677 μsec; net!io!ncpu
vbt May 14 21:27:57 rexcall:dialing 1082 μsec; net!io!ncpu
vbt May 14 21:27:58 rexcall:dial 1109949 μsec
replacing
na = netmkaddr(host, 0, service);
by
na = netmkaddr(host, “tcp”, service);
we get much better performance as shown below.
vbt May 14 22:21:18 rexcall:netmkaddr 489 μsec; tcp!io!ncpu
vbt May 14 22:21:18 rexcall:dialing 861 μsec; tcp!io!ncpu
vbt May 14 22:21:18 rexcall:dial 3099 μsec
vbt May 14 22:21:22 rexcall:netmkaddr 565 μsec; tcp!io!ncpu
vbt May 14 22:21:22 rexcall:dialing 977 μsec; tcp!io!ncpu
vbt May 14 22:21:22 rexcall:dial 7287 μsec
isn’t it better the default net be “tcp”?
even if you do want “net”, you can do
cpu -h net!host
Kenji Arisawa
> 2016/05/13 0:40、Skip Tavakkolian のメール：
>
> it might be worth instrumenting the cpu command to time the authenticaiton
> step. i think that's where the problem is.
>
> On Wed, May 11, 2016 at 3:39 PM Skip Tavakkolian
> wrote:
> what's the latency caused by the auth step?
> FYI, from Seattle I see about 8 seconds to establish but as Charles noted,
> it's reasonably fast after that.
>
>
> On Wed, May 11, 2016 at 2:05 PM arisawa wrote:
> Hello,
>
> we can measure the latency that comes from network connection
> by executing simple program such as telnet or something others
> to the port 8006 of grid.nyx.link. the content is:
> #!/bin/rc
> cat $net/local
> cat $net/remote
>
> yes the DNS may make a problem in IPv4/IPv6 mixed environment.
> my server supports both IPs.
> the cpu command will select IPv4. the command does not have “-6” option.
> If we want to connect by IPv6, literal IP address is required in the argument
> of the command.
>
> Kenji Arisawa
>
> > In my experience, it's almost unfailingly the DNS that slows down
> > establishing an Internet session of any type.
> >
> > Lucio.
>
> > 2016/05/12 0:23、Kenny Lasse Hoff Levinsen のメール：
> >
> > Well, based on the 9fs test that was posted, I'd think dial is being
> > awfully slow.
> >
> > Maybe try something simpler? aux/listen1 echo hello and a simple network
> > connection?
> >
> > Best regards,
> > Kenny Levinsen
> >
> > On 11. maj 2016, at 16.13, Charles Forsyth
> > wrote:
> >
> >>
> >> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen
> >> wrote:
> >> Delete the channel from /srv in the loop to test a full remote mount
> >> dance, including the initial dial. It shouldn't take 3s to dial, though.
> >>
> >> There's something initially slow in connecting to grid.nyx.link with cpu,
> >> and setting up, but once there it's fine.
>
>
[9fans] bug in authdial()
Hello,
authdial() is slow. so I have inspected the code:
/sys/src/libauthsrv/authdial.c
I suspect netroot causes the problem.
int
authdial(char *netroot, char *dom)
{
[snip]
if(dom == nil)
/* look for one relative to my machine */
return dial(netmkaddr("$auth", netroot, "ticket"), 0, 0, 0);
/* look up an auth server in an authentication domain */
p = csgetvalue(netroot, "authdom", dom, "auth", &t);
/* if that didn't work, just try the IP domain */
if(p == nil)
p = csgetvalue(netroot, "dom", dom, "auth", &t);
[snip]
for(nt = t; nt != nil; nt = nt->entry) {
if(strcmp(nt->attr, "auth") == 0) {
p = netmkaddr(nt->val, netroot, "ticket");
rv = dial(p, 0, 0, 0);
if(rv >= 0)
break;
}
}
[snip]
}
man authsrv(2) says:
the default of netroot in authdial(char *netroot, char *ad) is “/net”
and consistent with the synopsis of csgetvalue(char *netroot, char *attr, char
*val,….).
on the other hand the synopsis of netmkaddr is
char* netmkaddr(char *addr, char *defnet, char *defservice)
the defnet takes values nil, “tcp”, “il”, etc.
as the result, netroot in the first argument of authdial() works only if it is
nil, which makes authdial()
very slow.
I think that should be fixed for example:
- p = netmkaddr(nt->val, netroot, "ticket");
rv = dial(p, 0, 0, 0);
if(rv >= 0)
break;
+ p = netmkaddr(nt->val, “tcp", "ticket");
rv = dial(p, 0, 0, 0);
if(rv >= 0)
break;
+ p = netmkaddr(nt->val, “il", "ticket");
+ rv = dial(p, 0, 0, 0);
+ if(rv >= 0)
+ break;
NOTE that
return dial(netmkaddr("$auth", netroot, "ticket"), 0, 0, 0);
should be also fixed.
Kenji Arisawa
Re: [9fans] cpu command latency
Hello,
fixing authdial bug I got remarkable result.
I measured using mobile wireless network (the bandwidth is a few tens mega bps).
before fixing:
0.00u 0.00s 44.73r cpu -h grid.nyx.link -k
dom=outside.plan9.bell-labs.com ...
0.00u 0.00s 9.35rcpu -h grid.nyx.link -k
dom=outside.plan9.bell-labs.com ...
0.00u 0.01s 9.39rcpu -h grid.nyx.link -k
dom=outside.plan9.bell-labs.com ...
after fixing:
0.00u 0.01s 14.59r cpu -h tcp!grid.nyx.link -k dom=luna.nyx.link ...
0.00u 0.04s 7.65rcpu -h tcp!grid.nyx.link -k dom=luna.nyx.link ...
0.00u 0.00s 7.51rcpu -h tcp!grid.nyx.link -k dom=luna.nyx.link ...
you need to recompile libauthsrv, factotum and kernel.
I am happy if anyone send me data from outside of japan.
putting “tcp!” is clumsy. fixing cpu.c is also desirable.
p.s. thanks skip for the suggestion.
Kenji Arisawa
> 2016/05/14 22:30、arisawa のメール：
>
> Hello
>
> this is a partial report of cpu command latency.
>
> we have code below in rexcall() of cpu.c
>
> na = netmkaddr(host, 0, service);
> //na = netmkaddr(host, “tcp”, service);//DBG
> syslog(0,"cpu","rexcall:netmkaddr %lld μsec;
> %s",(nsec()-t0)/1000,na);//DBG
> procsetname("dialing %s", na);
> syslog(0,"cpu","rexcall:dialing %lld μsec;
> %s",(nsec()-t0)/1000,na);//DBG
> if((*fd = dial(na, 0, devdir, 0)) < 0)
> return "can't dial";
> syslog(0,"cpu","rexcall:dial %lld μsec",(nsec()-t0)/1000);//DBG
>
> lines with “DBG” are code added for measurement.
> looking the result I found dial() takes as much as on second in my home
> network!
>
> vbt May 14 21:27:52 rexcall:netmkaddr 122 μsec; net!io!ncpu
> vbt May 14 21:27:52 rexcall:dialing 592 μsec; net!io!ncpu
> vbt May 14 21:27:53 rexcall:dial 1161556 μsec
>
> vbt May 14 21:27:57 rexcall:netmkaddr 677 μsec; net!io!ncpu
> vbt May 14 21:27:57 rexcall:dialing 1082 μsec; net!io!ncpu
> vbt May 14 21:27:58 rexcall:dial 1109949 μsec
>
> replacing
> na = netmkaddr(host, 0, service);
> by
> na = netmkaddr(host, “tcp”, service);
> we get much better performance as shown below.
> vbt May 14 22:21:18 rexcall:netmkaddr 489 μsec; tcp!io!ncpu
> vbt May 14 22:21:18 rexcall:dialing 861 μsec; tcp!io!ncpu
> vbt May 14 22:21:18 rexcall:dial 3099 μsec
>
> vbt May 14 22:21:22 rexcall:netmkaddr 565 μsec; tcp!io!ncpu
> vbt May 14 22:21:22 rexcall:dialing 977 μsec; tcp!io!ncpu
> vbt May 14 22:21:22 rexcall:dial 7287 μsec
>
> isn’t it better the default net be “tcp”?
> even if you do want “net”, you can do
> cpu -h net!host
>
> Kenji Arisawa
>
>
>
>> 2016/05/13 0:40、Skip Tavakkolian のメール：
>>
>> it might be worth instrumenting the cpu command to time the authenticaiton
>> step. i think that's where the problem is.
>>
>> On Wed, May 11, 2016 at 3:39 PM Skip Tavakkolian
>> wrote:
>> what's the latency caused by the auth step?
>> FYI, from Seattle I see about 8 seconds to establish but as Charles noted,
>> it's reasonably fast after that.
>>
>>
>> On Wed, May 11, 2016 at 2:05 PM arisawa wrote:
>> Hello,
>>
>> we can measure the latency that comes from network connection
>> by executing simple program such as telnet or something others
>> to the port 8006 of grid.nyx.link. the content is:
>> #!/bin/rc
>> cat $net/local
>> cat $net/remote
>>
>> yes the DNS may make a problem in IPv4/IPv6 mixed environment.
>> my server supports both IPs.
>> the cpu command will select IPv4. the command does not have “-6” option.
>> If we want to connect by IPv6, literal IP address is required in the
>> argument of the command.
>>
>> Kenji Arisawa
>>
>>> In my experience, it's almost unfailingly the DNS that slows down
>>> establishing an Internet session of any type.
>>>
>>> Lucio.
>>
>>> 2016/05/12 0:23、Kenny Lasse Hoff Levinsen のメール：
>>>
>>> Well, based on the 9fs test that was posted, I'd think dial is being
>>> awfully slow.
>>>
>>> Maybe try something simpler? aux/listen1 echo hello and a simple network
>>> connection?
>>>
>>> Best regards,
>>> Kenny Levinsen
>>>
>>> On 11. maj 2016, at 16.13, Charles Forsyth
>>> wrote:
>>>
>>>>
>>>> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen
>>>> wrote:
>>>> Delete the channel from /srv in the loop to test a full remote mount
>>>> dance, including the initial dial. It shouldn't take 3s to dial, though.
>>>>
>>>> There's something initially slow in connecting to grid.nyx.link with cpu,
>>>> and setting up, but once there it's fine.
>>
>>
>
>
Re: [9fans] bug in authdial()
hello, thanks for the information. the lookup depends on dns cache but I also don’t think it has a problem. I think the negotiation process is innocent. plan9 auth negotiation is fairly simple, that needs only a single step: C→A: ticket request A→C: encrypted ticket I measured the times that are required for the auth server to complete the ticket request. they are only a few milliseconds. dialing time from client to auth server is the problem. > 2016/05/19 2:03、Skip Tavakkolian のメール： > > i don't think it's the auth lookup: > > supermic% time ndb/csquery /net/cs net!luna.nyx.link!ticket > /net/tcp/clone 115.36.102.252!567 > /net/tcp/clone 2402:6b00:4040:b600::8!567 > 0.00u 0.00s 0.34r ndb/csquery /net/cs net!luna.nyx.link!ticket > supermic% time ndb/csquery /net/cs net!grid.nyx.link!cpu > /net/tcp/clone 115.36.102.252!17010 > /net/tcp/clone 2402:6b00:4040:b600::9!17010 > 0.00u 0.00s 0.01r ndb/csquery /net/cs net!grid.nyx.link!cpu > supermic% > > i suspect it's auth negotiations. > > > > On Wed, May 18, 2016 at 6:07 AM Charles Forsyth > wrote: > > On 18 May 2016 at 01:43, arisawa wrote: > - p = netmkaddr(nt->val, netroot, "ticket"); > rv = dial(p, 0, 0, 0); > if(rv >= 0) > break; > > + p = netmkaddr(nt->val, “tcp", "ticket"); > rv = dial(p, 0, 0, 0); > if(rv >= 0) > break; > + p = netmkaddr(nt->val, “il", "ticket"); > + rv = dial(p, 0, 0, 0); > + if(rv >= 0) > + break; > > But that's just (eventually) moving the cs search into every application and > bound to specific network types. > Why is the cs search with "net" so slow?
Re: [9fans] bug in authdial()
cinap is right but I wonder if we should take care of IL forever. > 2016/05/18 18:14、cinap_len...@felloff.net のメール： > > yes, passing netroot to netmkaddr() is wrong. however, i dont see where > we pass anything other than netroot=nil to authdial(). > > i suspect what you'r experiencing is that dial() tried IL first (with > !fasttimeout option), which fails and then tries TCP causing the delay. > > so you changing it to try tcp first gets rid of the delay (but will break > the unlikely case where you got an authserver running on IL only as tcp > has no fast timeout option). > > -- > cinap >
Re: [9fans] bug in authdial()
nice idea. I’ve put an option to cs so that il isn’t listed first. > 2016/05/20 0:48、Charles Forsyth のメール： > > It's not just il. There are other networks, other protocols, other than tcp > and IP. > It's one of the advantages of plan 9 that it's easy to try and use new ones. > cs could present a different search list when there's only one way to get > somewhere. > as a quick fix for everything, if you're not using il, remove it from the > list in ndb/cs.c, and cs won't suggest it. > > > On 19 May 2016 at 16:43, wrote: > > cinap is right but I wonder if we should take care of IL forever. > > Yes. > > Lucio. > > >
Re: [9fans] bug in authdial()
I am sorry that I didn’t give enough information but I din’t know there is so much difference on the subject among 9front, 9atom and labs plan9. > 2016/05/21 7:04、Skip Tavakkolian <9...@9netics.com> のメール： > > i'm a little confused by the discussion of ...
Re: [9fans] bug in authdial()
parallel dialing would be fine. I guess both cinap and erik have examined labs code. any problem with it? > 2016/05/21 7:25、Charles Forsyth のメール： > > > On 20 May 2016 at 23:04, Skip Tavakkolian <9...@9netics.com> wrote: > i'm a little confused by the discussion of il + tcp on authdial > causing the delay. if ndb/cs returns multiple dial strings, dialmulti > function (/sys/src/libc/9sys/dial.c) dials them all in parallel > (rfork) and the first one that returns, wins. > > 9front uses the original sequential one
Re: [9fans] bug in authdial()
Hello,
> 2016/05/21 11:25、Skip Tavakkolian <9...@9netics.com> のメール：
>
> i think this fix is correct; i'm not sure why tokenize didn't have a
> problem walking a buffer it expects to be null terminated.
I agree with skip.
the man wait(2) says:
The underlying system call is await, which fills in the n-
byte buffer s with a textual representation of the pid,
times, and exit string. There is no terminal NUL. The
return value is the length, in bytes, of the data.
thus the typical usage of await is:
Waitmsg*
wait(void)
{
int n, l;
char buf[512], *fld[5];
Waitmsg *w;
n = await(buf, sizeof buf-1);
if(n < 0)
return nil;
buf[n] = '\0';
if(tokenize(buf, fld, nelem(fld)) != nelem(fld)){
werrstr("couldn't parse wait message");
return nil;
}
/sys/src/libc/9sys/dial.c may be fixed as follows:
static int
reap(Dest *dp)
{
char exitsts[2*ERRMAX];
+ int n;
- if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) {
+ if (outstandingprocs(dp) && (n = await(exitsts, sizeof exitsts-1)) >=
0) {
+ exitsts[n] = 0;
notedeath(dp, exitsts);
return 0;
}
return -1;
}
probably 2*ERRMAX is enough for await().
I wonder why await() returns non-terminated string?
Re: [9fans] bug in authdial()
hello skip, it is too late but I should say many thanks. > 2016/05/21 7:04、Skip Tavakkolian <9...@9netics.com> のメール： > > supermic% time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' -c > pwd > dial took: 165268068 ns > negotiate auth took: 159047373 ns > factotum autenticate took: 699255914 ns > lclnoteproc time: 702945750 ns > far end setup time: 157257845 ns > /usr/fst > 0.00u 0.00s 7.58r ./cpu -h grid.nyx.link -k > dom=outside.plan9.bell-labs.com ... > supermic% time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' > -c pwd > dial took: 158312233 ns > negotiate auth took: 155598573 ns > factotum autenticate took: 681558002 ns > lclnoteproc time: 684863443 ns > far end setup time: 151972579 ns > /usr/fst > 0.00u 0.01s 7.22r ./cpu -h grid.nyx.link -k > dom=outside.plan9.bell-labs.com ... > supermic% time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' > -c pwd > dial took: 176752321 ns > negotiate auth took: 175402567 ns > factotum autenticate took: 746787405 ns > lclnoteproc time: 749881615 ns > far end setup time: 172600395 ns > /usr/fst > 0.00u 0.03s 8.17r ./cpu -h grid.nyx.link -k > dom=outside.plan9.bell-labs.com ... > supermic% > >
Re: [9fans] plan9.bell-labs.com hates AppleWebKit?
I can get proper response from http://plan9.bell-labs.com/sources/ by using mac/osx safari. > 2016/10/03 2:42、James A. Robinson のメール： > > So... Does Alcatel-Lucent have a problem with AppleWebKit > users on principle? > > It looks to me as though my problem with browsing around > under http://plan9.bell-labs.com/sources/ (and other subpages) > is because the server doesn't like the User-Agent string: > > $ telnet plan9.bell-labs.com 80 > Trying 135.104.24.16... > Connected to plan9.bell-labs.com. > Escape character is '^]'. > GET /sources/contrib/ HTTP/1.1 > Host: plan9.bell-labs.com > Connection: keep-alive > Cache-Control: max-age=0 > Upgrade-Insecure-Requests: 1 > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 > Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > DNT: 1 > Accept-Encoding: gzip, deflate, sdch > Accept-Language: en-US,en;q=0.8 > > HTTP/1.1 200 OK > Connection closed by foreign host. > > And here it is again w/o the User-Agent string: > > $ telnet plan9.bell-labs.com 80 > Trying 135.104.24.16... > Connected to plan9.bell-labs.com. > Escape character is '^]'. > GET /sources/contrib/ HTTP/1.1 > Host: plan9.bell-labs.com > Connection: keep-alive > Cache-Control: max-age=0 > Upgrade-Insecure-Requests: 1 > Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > DNT: 1 > Accept-Encoding: gzip, deflate, sdch > Accept-Language: en-US,en;q=0.8 > > HTTP/1.1 200 OK > Server: Plan9 > Date: Sun, 02 Oct 2016 17:29:09 GMT > Connection: close > Last-Modified: Fri, 14 Mar 2014 22:14:11 GMT > Content-Type: text/html > > [... proper body returned...] > > I tried playing around with the UA value and found that if I change > AppleWebKit to something else such as AppleWebKis I get a > response... > > Jim >
Re: [9fans] 9front on raspberry pi
thanks, i will try. is this for pi1 or pi2 or both? > 2016/11/02 10:35、Chris McGee のメール： > > Hi All, > > I have released an experimental 9front raspberry pi image that I use for my > cluster. > https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016 > > Highlights: > -Latest 9front release 2016-10-27 > -Merged in Richard Millar’s kernel from a couple of months ago > -Retains 9front GPIO filesystem structure > -Link local ipv4 address on boot (low likelihood of collisions) > -Discovery of other nodes using multicast DNS through the ‘find9p’ command > -9fs mount other nodes on the network > -Go 1.7.3 > -Git script (works with github and google source repos) > > Cheers, > Chris
Re: [9fans] 9front on raspberry pi
I’ve tried both pi1 and pi2. both devices successfully boot up. my impression only in primitive usage is: pi2 is fine. thanks Chris! pi1 is a bit unsteady on usb device. usb keyboard is sometimes accidentally detached. > 2016/11/02 14:05、arisawa のメール： > > thanks, i will try. > > is this for pi1 or pi2 or both? > >> 2016/11/02 10:35、Chris McGee のメール： >> >> Hi All, >> >> I have released an experimental 9front raspberry pi image that I use for my >> cluster. >> https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016 >> >> Highlights: >> -Latest 9front release 2016-10-27 >> -Merged in Richard Millar’s kernel from a couple of months ago >> -Retains 9front GPIO filesystem structure >> -Link local ipv4 address on boot (low likelihood of collisions) >> -Discovery of other nodes using multicast DNS through the ‘find9p’ command >> -9fs mount other nodes on the network >> -Go 1.7.3 >> -Git script (works with github and google source repos) >> >> Cheers, >> Chris > >
Re: [9fans] 9front on raspberry pi
hi steve > 2016/11/02 16:57、Steve Simon のメール： > > can you tell me what the gpio file system looks like try ls -l '#G' them you will find some files such as #G/gpio/CE0 #G/gpio/CE1 #G/gpio/GPI00 #G/gpio/GPI01 ... #G/gpio/ctl #G/gpio/event but something weird. term% mount -a '#G' /dev mount: can’t open '#G': permission denied I don’t know the reason. I haven’t tried GPIO nor mDNS yet, sorry. using large display is frustrating... my portable HDMI display of 1280x800 works fine.
