Hi, On Wed, Jul 23, 2014 at 11:43:27PM +0200, Jan Just Keijser wrote: > >Gert, we are sure, there was not a problem with the resources (eg.: > >max open files, max filed descriptors, etc.) on the system. > >What else can I do about it? > > > try debugging this by adding some statements to the client-connect > script, e.g. > > ls -l /proc/self/fd/* | wc -l >> /tmp/debug.log > sysctl fs.file-nr >> /tmp/debug.log > > to find out if there really are no more filehandles available. > For each connection a new client-connect script is started, so I doubt > that any non-closed file handles will accumulate and cause this problem.
The error message came from OpenVPN, so if there is a leak, it's in
OpenVPN, not in the script.
OTOH, we use openvpn (git master) with client-connect scripts and
per-user generated configs on a moderately-loaded system, and have
not run into fd exhaustion issues - and lsof doesn't print anything
interesting either, so it must be something more interesting than
a forgotten close() call...
Arno, are you using plugins? (A plugin runs in the OpenVPN context,
and if a plugin leaks FDs, it will affect OpenVPN as well)
How does a "lsof -p $processid" for the OpenVPN process look like after
it has run for a few hours? Mine shows about 20 lines, and most of them
are shared libraries (/lib/...*.so.*) - if it is significantly more for
you, there is the problem.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpM_z8KSwnNg.pgp
Description: PGP signature
