New issue 7 by mirekm967: High network usage on system using ldap
authentication
http://code.google.com/p/socket-sentry/issues/detail?id=7
When the system is configured to use LDAP for user authentication and as
user base, then socksent-service is continuously exchanging high amount of
the data with ldap server.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
Is your LDAP server also your DNS server? If so, this is expected behavior
if you've
enabled host name lookups. Socket Sentry does not initiate traffic with any
server
other than the DNS server. (And even those results are cached.)
Comment #2 on issue 7 by r...@hasselbaum.net: High network usage on system
using ldap authentication
http://code.google.com/p/socket-sentry/issues/detail?id=7
Marking INVALID on assumption that this is really DNS traffic, since SS
doesn't
participate in any other kind of traffic. To eliminate DNS queries, host
name lookups
should be disabled (the default).
No it is not.
I dumped packets exchaged between socksent-service and ldap server, and it
seems, that
the service is asking for user using kde before each refreshing of applet
data. I
thing that the user info, should be saved somewhere once access is granted.
Comment #4 on issue 7 by r...@hasselbaum.net: High network usage on system
using ldap authentication
http://code.google.com/p/socket-sentry/issues/detail?id=7
Ahh, OK, this is because SS is asking libc to supply the owner of each
process and on
machines that use LDAP, this must be causing a network round trip. I'll
have to see
if there's another way to get (or at least cache) this data.
Comment #5 on issue 7 by r...@hasselbaum.net: High network usage on system
using ldap authentication
http://code.google.com/p/socket-sentry/issues/detail?id=7
(No comment was entered for this change.)
Comment #6 on issue 7 by r...@hasselbaum.net: High network usage on system
using ldap authentication
http://code.google.com/p/socket-sentry/issues/detail?id=7
Upgrading to high. Should try to resolve in the next point release.
Comment #7 on issue 7 by r...@hasselbaum.net: High network usage on system
using ldap authentication
http://code.google.com/p/socket-sentry/issues/detail?id=7
Couldn't find anything in /proc. The "ps" command uses the same libc call.
The "top"
command does, as well, but it has a cache. I suppose that's the way to go,
even
though I intended for SS to maintain radio silence unless host lookups was
turned on.
Comment #8 on issue 7 by r...@hasselbaum.net: High network usage on system
using ldap authentication
http://code.google.com/p/socket-sentry/issues/detail?id=7
Fixed in revs f5905277f9 and 1e4c345d27 to land in release 0.9.2. SS now
performs
process owner username lookups asynchronously and caches the results.
I found the reason of the bug. There were two things together.
One of them was crash of nscd, there is bug in glibc since about 3 years,
that is
not corrected until now. Now I switched to unscd, and it solves problem of
big data
exchange.
But from the side of socketsentry there is still an issue. If nscd is not
running,
socketsentry ask ldap for user/group of each task accessing the network.
Once it
started asking the ldap, it access the network by itself, and asks for
username of
socksent-service, and then it is going to endless loop. If all other jobs
don't
connect the network, socksent-service do, becuase it asks for the user
assigned to
itself.
Since unscd daemon is running, this problem don't disturb me as well. So if
you
like, you could change this behavior (so the socksent-service remember
association
of user and group to itself).
Anyway Thank you very much for good job.
As of release 0.9.2, Socket Sentry is caching the results of user database
lookups
itself. Even if it does not get a response from libc, it will not request a
lookup
for the same UID again until its own cache entry expires some time later. I
think
that solves the problem even if libc/nscd misbehaves.