Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <749228e2-4d49-83ef-06f0-2db0532beb93@systech.com>
In-Reply-To: <749228e2-4d49-83ef-06f0-2db0532beb93@systech.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Fri, 4 Jun 2021 14:39:07 -0700
Message-ID: <CABBYNZJeEV-4-fhGAwzqu0e+J3DN9Bm8pDk1s29myUdRF29jUQ@mail.gmail.com>
Subject: Re: Bluez Socket File Descriptor Leak
To:     jay@systech.com
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Jay,

On Fri, Jun 4, 2021 at 12:14 PM Jay Foster <jay@systech.com> wrote:
>
> I am experiencing an odd problem with PAN networking.  I have PAN
> networking setup in NAP role.  Another machine makes a BNEP connection
> and performs network activity, then disconnects the BNEP connection.
> This repeats periodically.  This works just fine, except after a while,
> the BNEP connection fails with the following in the log.
>
> May  4 13:08:02 (none) daemon.debug bluetoothd[1373]:
> profiles/network/server.c:confirm_event() BNEP: incoming connect from
> B8:27:EB:E5:35:9B
> May  4 13:08:03 (none) daemon.err bluetoothd[1373]: Can't add bnep0 to
> the bridge br1: Too many open files(24)
>
> ls /proc/`pidof bluetoothd`/fd shows about 1000 open file descriptors
> (sockets mostly).  This looks like some kind of resource (file
> descriptor) leak.
>
> Has anyone experienced this before?  I don't know if it is in the
> bluetoothd application or one if the libraries (glib2, dbus) it links
> with.  Happens with bluez 5.19 and 5.52.

That looks like the fd are not released (via close) after they are
attached to the bridge, you could in theory increase the number of fd
a process can have in the meantime but we will need to fix this
problem at some point so please have a issue created in github:

https://github.com/bluez/bluez/

-- 
Luiz Augusto von Dentz