[Date Prev][Date Next] [Chronological] [Thread] [Top]

slurpd hangs after some hours

Using OpenLDAP 2.0.27.  Master slapd.conf contains:

replica host="slave.host.fqdn"
        tls=yes
        bindmethod=sasl
        saslmech=GSSAPI

replogfile /var/db/ldap/replication.log

Replication works fine for some period of time (hours) and then stops
working.  ps of slurpd shows:

ldap      4677     1  0 May09 ?        00:00:00 /usr/local/libexec/slurpd
ldap      4678  4677  0 May09 ?        00:00:01 /usr/local/libexec/slurpd
ldap      4679  4678  0 May09 ?        00:00:03 /usr/local/libexec/slurpd
ldap      4680  4678 89 May09 ?        3-05:57:48 /usr/local/libexec/slurpd

top shows:

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 4680 ldap      25   0 11532  10M  1820 R    99.9  1.0  4678m slurpd

Other details:
 - /var/db/ldap/replication.log is empty;
 - openldap-slurp/replica/slurpd.replog contains up-to-the-minute ldif;
 - openldap-slurp/replica/slurpd.status shows a timestamp of the same time
   as the last MOD operation logged on the slave.

There is a cron job that renews the kerberos ticket (runs a kinit) for the
GSSAPI authentication, but the hang in slurpd does not correspond to the
cron schedule (every 6 hours).  It DOES approximately correspond to the
expiration of the tgt that was there when slurpd started.  I'm assuming
that this might be the cause: slurpd establishes a connection and never
closes it; I speculate that it caches the tgt internally and never
re-reads it from disk; eventually the ticket expires and something goes
haywire in slurpd.

Should I be stopping/starting slurpd each time I renew the ticket?  Is
there a better approach?

Allan
--
"If you understand what you're doing, you're not learning anything."
                                                -- Anonymous