slapd stuck?

Forums Network Management ZeroShell slapd stuck?

  • This topic is empty.
Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #43298

    I recently upgraded from b14 to b16, and all went smoothly until today, when I attempted to modify one of my DNS entries. Using the web interface, I attempted to remove one of the CNAME aliai so I could then re-add it as a seperate address. The interface appeared to lock up.

    I could then go to other parts of the interface (DHCP, QoS, etc), but the DNS page returned nothing. Using ssh, I could log in and see slapd taking 98.9% of the CPU.

    Rebooting resulted in a corrupt LDAP database. I restored from a backup and tried copying one of the reverse DNS entries, resulting in the same situation.

    I never had any issues like this in b14, so I’m wondering if something may have changed in the way LDAP data is updated, or perhaps a newer version of slapd that has a bug is present?

    For the time being, I will likely downgrade to the earlier version and see if this dodges the issue for now.

    Thanks for a great product! In the year and a half I’ve been using ZeroShell, this is the first real issue I’ve encountered. Pretty good track record IMHO. 🙂

    EDIT: Just in case it might be helpful, in perusing the log data, I noticed the following entry in named’s log:

    14:00:19 client update ‘’ denied

    It doesn’t seem like this should cause a lockup, but it also seems unusual for the machine to be denying itself.

    EDIT 2: Still does this with b14 as well. The action wich causes slapd to lock up at 99% CPU indefinately is selecting a valid DNS entry (such as a CNAME) and choosing the DELETE option. I’ve let this hang for hours and it never resolves. From that point onwards, named is unresponsive and the system has to be rebooted, which corrupts the LDAP database for named.


    So, still no solution here.

    Is there any way to export the data from LDAP and re-import it again? It seems bad to forever lose certain names because the delete operation won’t work, and also seems inelegant to have to retype 30 or 40 DNS entries to re-enter ALL of them except the one I wanted to remove.

    I believe my system started with version b11 or b12, and has not issued any errors or warnings as I’ve upgraded, but maybe one of the data migration tasks corrupted something?


    Hmmm, I just had this happen again while trying to add a brand new DNS A record. That moves this from annoying issue that can be worked around, to bug that makes my system impossible to administrate.

    Having to manually re-enter all of my settings from a fresh build doesn’t seem acceptable to me.

    Just to recap, whenever I attempt ANY modification to a DNS entry, either adding a new one or deleting an exsiting one, the DNS subsystem locks up, named stops responding to queries, and LDAP’s slapd process sits using 99% of the CPU for as long as I let it hang.

    One forced reboot, LDAP Recovery also sits and hangs for as long as I’m willing to leave my network offline. The only option I’m left with is to restore a backup of my USB stick, which works but doesn’t allow me to make any changes to the DNS system.

    My backup was from version 1.0.beta14, and I have tried booting with both b14 and b16 CD’s, neither one seems to make any difference. I believe I started using this at 1.0.beta12.

    At some point, I will try to find the time to create an entirely new profile, natively under beta 16, and hand-enter ALL of my data again, but that’s several dozen DNS and DHCP entries, along with various firewall rules, QoS data, and other tweak I’ve likely forgotten. Not something I want to do more than once.

    I realize you probably can’t replicate the issue on your end, but since everything is hidden away in LDAP (which I’m not familiar with), I’m not quite sure where to look to try and figure out the problem. Any hints are appreciated!


    Here’s my progress, so far.

    I spent several hours re-entering all my data by hand on a freshly generated profile, native to 1.0b16. So far, it appears to be working as expected.

    One difference I noticed is the existence of DNS entries for kerberos, specifically an A record pointing to myself, a TXT record with the kerberos domain, and several SRV records for kerberos-adm, kerberos, and kpasswd. These were NOT present in my older DNS data, and were not added by the upgrade process from 1.0b12->14, or 14->16.

    IF something relies on those entries being present, that might well be the cause of the hang… however it’s only a guess.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.