> From: "Chris Garrigues" <cwg-oldap-sw@DeepEddy.Com>
> Date: Wed, 02 Feb 2000 11:13:53 -0600
>
> I'm getting kicked in the ass by syslog when I start using openldap through
> nss_ldap (tar, in particular, is deadly; you gotta love the complexity: I run
> amanda, which kicks off tar which checks all the UIDs which calls nss_ldap
> which calls openldap which calls syslog which uses all the CPU and amanda
> takes 3 days to complete). Since the problem is syslog and not openldap per
> se, I'm trying to figure out how to make the problem go away.
>
> Since I'm a qmail user, I already have cyclog on my systems, so I'm thinking
> about adapting openldap to use it. Before I dig too deep, does anyone have
> any experience doing this? "All" I would need is to send the logging info to
> stderr instead of calling syslog. How does the -d flag effect the syslogging?
Someone suggested (over lunch, not because of this post) that I use the '-' in
syslog.conf to make syslog behave better. Now instead of the machine hosing
up due to syslog eating up the CPU, I get a more complex set of symptoms.
When my partner paged me this morning, the load average was about 85 and we
couldn't su or log in. The system was responsive, but 'id' hung. We took
ldap back out of nsswitch.conf, then at least we could log in again, but the
load average remained high and some things still didn't work.
I found infinite numbers of CROND, (qmail-)imapd, and smbd processes running,
so I killed them and things got better.
Shortly afterwards, I found that /var was full (where the logging occurs); I
blew away some older ldap logs and noticed that my current ldap log (which is
too long to load into emacs) ends like this:
.
.
.
Feb 3 04:39:20 hackberry slapd[615]: conn=164760 op=-1 fd=28 closed errno=0
Feb 3 04:39:20 hackberry slapd[30991]: conn=164761 op=2 RESULT err=0 tag=101 nentries=0
Feb 3 04:39:20 hackberry slapd[30992]: conn=164760 op=3 UNBIND
Feb 3 04:39:20 hackberry slapd[615]: conn=164761 op=-1 fd=23 closed errno=0
Feb 3 04:39:20 hackberry slapd[30993]: conn=164762 op=0 BIND dn="" method=128
Feb 3 04:39:20 hackberry slapd[30993]: conn=164762 op=0 RESULT err=0 tag=97 nentries=0
Feb 3 04:39:20 hackberry slapd[30994]: conn=164762 op=1 SRCH base="DC=VIRCIO,DC=COM" scope=2 filter="(&(objectclass=POSIXGROUP)(gidnumber=234))"
Feb 3 04:39:20 hackberry slapd[30994]: conn=164762 op=1 RESULT err=9 tag=101 nentries=0
Feb 3 04:39:20 hackberry slapd[30995]: conn=164762 op=2 SRCH base="O=VIRCIO,C=US" scope=2 filter="(&(objectclass=POSIXGROUP)(gidnumber=234))"
Feb 3 04:39:20 hackberry slapd[30995]: conn=164762 op=2 RESULT err=0 tag=101 nentries=0
Feb 3 04:39:20 hackberry slapd[615]: conn=164763 fd=23 connection from hackberry.vircio.com (10.1.1.5) accepted.
Feb 3 04:39:20 hackberry slapd[30996]: conn=164762 op=3 UNBIND
Feb 3 04:39:20 hackberry slapd[30996]: conn=164762 op=3 fd=29 closed errno=0
Feb 3 04:39:20 hackberry slapd[30997]: conn=164763 op=0 BIND dn="" method=128
Feb 3 04:39:20 hackberry slapd[30997]: conn=164763 op=0 RESULT err=0 tag=97 nentries=0
Feb 3 04:39:20 hackberry slapd[30998]: conn=164763 op=1 SRCH base="DC=VIRCIO,DC=COM" scope=2 filter="(&(objectclass=POSIXGROUP)(gidnumber=234))"
Feb 3 04:39:20 hackberry slapd[30998]: conn=164763 op=1 RESULT err=9 tag=101 nentries=0
Feb 3 04:39:20 hackberry slapd[30999]: conn=164763 op=2 SRCH base="O=VIRCIO,C=US" scope=2 filter="(&(objectclass=POSIXGROUP)(gidnumber=234))"
Feb 3 04:39:20 hackberry slapd[30999]: conn=164763 op=2 RESULT err=0 tag=101 nentries=0
Feb 3 04:39:20 hackberry slapd[615]: conn=164763 op=-1 fd=23 closed errno=0
Feb 3 04:39:20 hackberry slapd[31000]: conn=164763 op=3 UNBIND
Feb 3 04:40:09 hackberry slapd[31009]: conn=157058 op=7 SRCH base="DC=VIRCIO,DC=COM" scope=2 filter="(&(objectclass=POSIXACCOUNT)(uid=IPC$))"
Feb 3 04:40:09 hackberry slapd[31009]: conn=157058 op=7 RESULT err=9 tag=101 nentries=0
Feb 3 04:40:09 hackberry slapd[31010]: conn=157058 op=8 SRCH base="O=VIRCIO,C=US" scope=2 filter="(&(objectclass=POSIXACCOUNT)(uid=IPC$))"
Feb 3 04:40:09 hackberry slapd[31010]: conn=157058 op=8 RESULT err=0 tag=101 nentries=0
Feb 3 04:40:09 hackberry slapd[31011]: conn=157058 op=9 SRCH base="DC=VIRCIO,DC=COM" scope=2 filter="(&(objectclass=POSIXACCOUNT)(uid=IPC$))"
Feb 3 04:40:09 hackberry slapd[31011]: conn=157058 op=9 RESULT err=9 tag=101 nentries=0
Feb 3 04:40:09 hackberry slapd[31012]: conn=157058 op=10 SRCH base="O=VIRCIO,C=US" scope=2 filter="(&(objectclass=POSIXACCOUNT)(uid=IPC$))"
Feb 3 04:40:09 hackberry slapd[31012]: conn=157058 op=10 RESULT err=0 tag=101 nentries=0
Feb 3 04:40:09 hackberry slapd[615]: conn=157058 op=-1 fd=19 closed errno=0
Feb 3 04:40:09 hackberry slapd[31013]: conn=157058 op=11 UNBIND
Feb 3 05:10:04 hackberry slapd[615]: conn=196 op=-1 fd=26 closed errno=0
Feb 3 09:03:55 hackberry slapd[615]: slapd shutting down - waiting for 0 threads to terminate
Feb 3 09:03:55 hackberry slapd[615]: slapd stopping
Feb 3 09:04:08 hackberry slapd[31963]: slapd starting
So, I suppose /var got full about 4:40:09 and the 5:10:04 entry was just lucky
as something else got deleted. The stop and start at the end were my doing.
Is there any reason to believe that throwing log info from slapd into the bit
bucket would make things any more stable.
Chris
--
Chris Garrigues virCIO
http://www.DeepEddy.Com/~cwg/ http://www.virCIO.Com
+1 512 432 4046 +1 512 374 0500
4314 Avenue C
O- Austin, TX 78751-3709
My email address is an experiment in SPAM elimination. For an
explanation of what we're doing, see http://www.DeepEddy.Com/tms.html
Nobody ever got fired for buying Microsoft,
but they could get fired for relying on Microsoft.
Attachment:
pgpgK0Rri39CM.pgp
Description: PGP signature