9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: arisawa <arisawa@ar.aichi-u.ac.jp>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] file descriptor leak
Date: Wed, 17 Feb 2016 10:13:49 +0900	[thread overview]
Message-ID: <E3DA9248-AAB9-4CA9-B91A-B7E206BED2BD@ar.aichi-u.ac.jp> (raw)
In-Reply-To: <CAOw7k5jtphVPgXd-ao=Dp6-TWoMC4mxxnTdY0upKJWq_ATxgrw@mail.gmail.com>

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         248    0:00   0:00      348K Await    dns
arisawa         249    0:00   0:00    14584K Pread    dns
arisawa         250    0:12   0:12    14576K Pread    dns
io% cat /proc/^(248 249 250)^/fd
/usr/arisawa
  0 r  M    8 (0000000000000005 0 00)  8192        1 /dev/cons
  1 w  c    0 (0000000000000002 0 00)     0        1 #c/cons
  2 w  c    0 (0000000000000002 0 00)     0      193 #c/cons
  3 r  c    0 (000000000000000f 0 00)     0        4 /dev/random
  4 w  M   22 (000000000000ce7e 54050 40)  8192  1098023 /sys/log/dns
  5 r  c    0 (0000000000000001 0 00)     0  6873616 /dev/bintime
  6 r  M   22 (000000000000929e 3098 00)  8192    10949 /lib/ndb/local
  7 r  M   22 (000000000000929b 47 00)  8192    10242 /lib/ndb/common
  8 r  I    0 (0000000000000004 3 00)     0      127 /net/ndb
  9 rw |    0 (0000000000000fc1 0 00) 65536     3954 #|/data
 11 w  s    0 (0000000000000009 0 00)     0        2 #s/dns
/usr/arisawa
  0 r  M    8 (0000000000000005 0 00)  8192        1 /dev/cons
  1 w  c    0 (0000000000000002 0 00)     0        1 #c/cons
  2 w  c    0 (0000000000000002 0 00)     0      193 #c/cons
  3 r  c    0 (000000000000000f 0 00)     0        4 /dev/random
  4 w  M   22 (000000000000ce7e 54050 40)  8192  1098023 /sys/log/dns
  5 r  c    0 (0000000000000001 0 00)     0  6873816 /dev/bintime
  6 r  M   22 (000000000000929e 3098 00)  8192    10949 /lib/ndb/local
  7 r  M   22 (000000000000929b 47 00)  8192    10242 /lib/ndb/common
  8 r  I    0 (0000000000000004 3 00)     0      127 /net/ndb
  9 rw |    0 (0000000000000fc1 0 00) 65536     3954 #|/data
 11 w  s    0 (0000000000000009 0 00)     0        2 #s/dns
 12 rw I    0 (000000000002002d 0 00)     0     3362 /net/udp/1/data
/usr/arisawa
  0 r  M    8 (0000000000000005 0 00)  8192        1 /dev/cons
  1 w  c    0 (0000000000000002 0 00)     0        1 #c/cons
  2 w  c    0 (0000000000000002 0 00)     0      193 #c/cons
  3 r  c    0 (000000000000000f 0 00)     0        4 /dev/random
  4 w  M   22 (000000000000ce7e 54050 40)  8192  1098023 /sys/log/dns
  5 r  c    0 (0000000000000001 0 00)     0  6873824 /dev/bintime
  6 r  M   22 (000000000000929e 3098 00)  8192    10949 /lib/ndb/local
  7 r  M   22 (000000000000929b 47 00)  8192    10242 /lib/ndb/common
  8 r  I    0 (0000000000000004 3 00)     0      127 /net/ndb
  9 rw |    0 (0000000000000fc1 0 00) 65536     3954 #|/data
 11 w  s    0 (0000000000000009 0 00)     0        2 #s/dns
 12 rw I    0 (000000000002002d 0 00)     0     3362 /net/udp/1/data
io% 


> 2016/02/17 7:24、Charles Forsyth <charles.forsyth@gmail.com> のメール:
> 
> 
> On 16 February 2016 at 15:52, arisawa <arisawa@ar.aichi-u.ac.jp> 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.




  reply	other threads:[~2016-02-17  1:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-16 15:52 arisawa
2016-02-16 15:56 ` Jacob Todd
2016-02-16 16:42   ` lucio
2016-02-16 17:05     ` Jacob Todd
2016-02-16 17:17     ` Charles Forsyth
2016-02-16 18:01 ` cinap_lenrek
2016-02-16 21:05   ` erik quanstrom
2016-02-16 21:16   ` Charles Forsyth
2016-02-17  2:19     ` cinap_lenrek
2016-02-22  5:18     ` erik quanstrom
2016-02-16 22:24 ` Charles Forsyth
2016-02-17  1:13   ` arisawa [this message]
2016-02-17  1:22     ` cinap_lenrek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E3DA9248-AAB9-4CA9-B91A-B7E206BED2BD@ar.aichi-u.ac.jp \
    --to=arisawa@ar.aichi-u.ac.jp \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).