Doing a kill -9 of ns-slapd, or doing a hard shutdown of a machine while ns-slapd is running, will cause a 0 length dse.ldif to be written
This is easy to reproduce in a VM: disable acpid, then do a force off
Reproduced the problem, now investigating. There are two issues here: 1] that a dse.ldif has 0 bytes 2] that at restart not the dse.ldif.bak is used, even if 1] could not comletely avoided when server is killed or machine powered off then fallback to dse.ldif.bak would allow to restart
I could reproduce the issue only when powering off a VM, by just killing the slapd process I couldn't. When reproducing I also always noticed the existence of a 0 byte dse.ldif.tmp file. From the code path writing updates to dse.ldif this cannot happen. We have a dse.ldif and a dse.ldif.bak while the server is running. If dse.ldif is to be modified we do: -create a dse.ldif.tmp (this is the only time a 0 byte dse.ldif* file exists -write the config to dse.ldif.tmp -rename dse.ldif to dse.ldif.bak -rename dse.ldif.tmp to dse.ldif So I assume the problem occurs in case of a machine crash when recovering the file system, but have no further insight.
But in the above scenario always a useful dse.ldif.bak does exist (maybe without the latest change). At startup the server should not only handle the case of a missing dse.ldif, but also if it exists and is empty as well as if the dse.ldif.tmp is missing or empty. The provided fix will handle this.
attachment 0001-Ticket-518-dse.ldif-is-0-length-after-server-kill-or.patch
git merge ticket518 Updating 8799a86..b3ca9ee Fast-forward ldap/servers/slapd/config.c | 32 +++++++------------------------- ldap/servers/slapd/dse.c | 60 +++++++++++++++++++++++++++++++++++++++--------------------- ldap/servers/slapd/proto-slap.h | 1 + 3 files changed, 47 insertions(+), 46 deletions(-)
git push origin master Counting objects: 15, done. Delta compression using up to 4 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 1.52 KiB, done. Total 8 (delta 6), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 8799a86..b3ca9ee master -> master
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=910581
Pushed to 389-ds-base-1.2.11: commit 8254669
Metadata Update from @lkrispen: - Issue assigned to lkrispen - Issue set to the milestone: 1.2.11.19
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/518
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.