Re: [9fans] file descriptor leak

> It's often better to use the Erlang fail-fast ("just fail") and restart > approach for persistent services. indeed. ndb/dns also has this "restart" ctl message where it restarts the server part but keeps the 9p pipe posted. tho that kills all the fid's and new fids starts as "dummy" user owned

Re: [9fans] file descriptor leak

looks good. thanks for reporting mr. arisawa. -- cinap

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

Re: [9fans] file descriptor leak

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

Re: [9fans] file descriptor leak

On 16 February 2016 at 18:01, wrote: > and the parent proc doesnt need the fd to /dev/null, it could as well just > open it in the child like: > > close(0); open("/dev/null", OREAD); > > There's no harm in making and using a more general function, even in a specific

Re: [9fans] file descriptor leak

> limitation on the number of processes that can be queued on a qlock()? in user space, yes. - erik

Re: [9fans] file descriptor leak

its worse. the static msg.msg is useless, its never set anywhere. the interface of system() makes no sense. its only used for running "outside" and the parent proc doesnt need the fd to /dev/null, it could as well just open it in the child like: close(0); open("/dev/null", OREAD); the caller

Re: [9fans] file descriptor leak

On 16 February 2016 at 16:42, wrote: > Then, it would be tempting to take the > > dup(fd,0); close(fd); > > out to before the if(pid==0)... > the idea is to have fd (/dev/null in this case) be standard input in the new process, so it needs to follow the pid==0

Re: [9fans] file descriptor leak

what's your fucking problem?

Re: [9fans] file descriptor leak

> I've had this problem too, I have yet to resolve it. You could start by tossing the very first and totally superfluous "else". to simplify things. Then, it would be tempting to take the dup(fd,0); close(fd); out to before the if(pid==0)... Well spotted, Kenji. Let's hope my shot

Re: [9fans] file descriptor leak

I've had this problem too, I have yet to resolve it. On Feb 16, 2016 10:54 AM, "arisawa" wrote: > Hello, > > I have observed warning messages from dns server: > dns 30792: warning process exceeded 100 file descriptors > dns 30888: warning process exceeded 200 file

[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

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:

Re: [9fans] 9pfuse and u9fs

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

[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