OpenLDAP start niet meer

[Verwijderd]

Ik heb al een behoorlijke tijd OpenLDAP draaien, versie 2.2.23. Door een probleempje heb ik laatst mijn servertje hard moeten resetten en nu start openldap niet meer. Als ik ldap start komen er geen foutmeldingen, hij doet ook iets maar pakt 99% cpu en bindt niet aan de interfaces. Normaal kreeg ik drie slapd-processen, maar het blijft er nu maar eentje. En hij zou zijn pid en args-file weg moeten schrijven maar dat gebeurt ook niet.

Ik vermoed dat het iets met de bdb-backend te maken heeft maar ik weet het niet zeker. Ik heb weinig verstand van berkeley databases, maar ik heb db4_recover -c -e -v gedaan en dat gaf geen foutmeldingen.

Als ik OpenLDAP start met volledige logging (/usr/local/libexec/slapd -d -1) krijg ik een hele hoop output zonder foutmeldingen met op het laatst

code:

slapd startup: initiated.
backend_startup: starting "dc=kitten,dc=its-s,dc=tudelft,dc=nl"
bdb_db_open: dc=kitten,dc=its-s,dc=tudelft,dc=nl
bdb_db_open: dbenv_open(/data/database/openldap)

En daarna dus niks meer. Uit logs van anderen op internet begrijp ik dat hierna nog de regel OpenLDAP started ofzoiets moet krijgen. Iemand een idee van wat er mis kan zijn?

[CyBeR]

Probeer 'm eens in strace te draaien en zie waar 'ie op blijft hangen.

[Verwijderd]

Ik heb

code:

strace /usr/local/libexec/slapd

gedaan, en dan krijg ik het volgende als laatste output (ik heb het meeste weggelaten want er lijkt niet echt iets fout te gaan, dit zijn de laatste regels die hij uitspuugt):

code:

getpid()                                = 16225
rt_sigaction(SIGPIPE, {0x40241c00, [], SA_RESTORER, 0x402b0db8}, {SIG_DFL}, 8) = 0
send(3, "<167>May  1 00:55:16 slapd[16225"..., 74, 0) = 74
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
read(7, "", 4096)                       = 0
read(7, "", 4096)                       = 0
close(7)                                = 0
munmap(0x40017000, 4096)                = 0
brk(0x8178000)                          = 0x8178000
rt_sigaction(SIGSTKFLT, {0x40241c00, [], SA_RESTORER|SA_RESTART, 0x402b0db8}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGSYS, {0x40241c00, [], SA_RESTORER|SA_RESTART, 0x402b0db8}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGHUP, {0x40241c00, [], SA_RESTORER|SA_RESTART, 0x402b0db8}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x40241c00, [], SA_RESTORER|SA_RESTART, 0x402b0db8}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x40241c00, [], SA_RESTORER|SA_RESTART, 0x402b0db8}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTRAP, {0x40241c00, [], SA_RESTORER|SA_RESTART, 0x402b0db8}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGCHLD, {0x40241c00, [], SA_RESTORER|SA_RESTART, 0x402b0db8}, {SIG_DFL}, 8) = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
fork()                                  = 16226
exit_group(0)                           = ?

en hij stopt direct. Betekent dat dat er iets mis gaat bij het fork-en?

[CyBeR]

Nee, dat is een daemonization. Doe 't nog eens maar dan even zorgen dat 'ie ook in de foreground blijft draaien, en dus niet van je terminal detached. Anders zie je idd een fork() en is 't klaar.

[Verwijderd]

met

code:

strace /usr/local/libexec/slapd -d 0

krijg ik het volgende resultaat (weer de laatste paar regels):

code:

read(7, "/dev/hda1 / reiserfs rw 0 0\nproc"..., 4096) = 282
close(7)                                = 0
munmap(0x40017000, 4096)                = 0
open("/proc/stat", O_RDONLY)            = 7
fstat64(7, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0
x40017000
read(7, "cpu  4271589 0 2040867 51934873\n"..., 4096) = 362
read(7, "", 4096)                       = 0
close(7)                                = 0
munmap(0x40017000, 4096)                = 0
stat64("/data/database/openldap/DB_CONFIG", 0xbffff520) = -1 ENOENT (No such fil
e or directory)
open("/data/database/openldap/DB_CONFIG", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
stat64("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=48, ...}) = 0
stat64("/data/database/openldap/__db.001", {st_mode=S_IFREG|0600, st_size=8192,
...}) = 0
open("/data/database/openldap/__db.001", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600
) = -1 EEXIST (File exists)
open("/data/database/openldap/__db.001", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600
) = -1 EEXIST (File exists)
open("/data/database/openldap/__db.001", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600
) = -1 EEXIST (File exists)
open("/data/database/openldap/__db.001", O_RDWR|O_LARGEFILE) = 7
fcntl64(7, F_SETFD, FD_CLOEXEC)         = 0
fstat64(7, {st_mode=S_IFREG|0600, st_size=8192, ...}) = 0
close(7)                                = 0
open("/data/database/openldap/__db.001", O_RDWR|O_LARGEFILE) = 7
fcntl64(7, F_SETFD, FD_CLOEXEC)         = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 0x40017000
close(7)                                = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0

en dat sched_yield() gaat nog in de eeuwigheid door ..

Er staat een foutmelding in over een niet-bestaande DB_CONFIG, die bestaat inderdaad niet. Ik weet niet of hij ooit wel bestaan heeft, maar het lijkt me sterk dat die zomaar weg zou zijn.

[Verwijderd]

Na zoeken op sched_yield() = 0 blijkt dit vooral bij openldap voor te komen db4_recover -h op de directory gedaan en hij start weer! Toch corrupte database blijkbaar. Tnx!!!

[_JGC_]

die DB_CONFIG gooi je neer in de directory waar je ldap database komt te staan, voordat je begint met het aanmaken ervan (slapcat -l backup.ldif; openldap db files weggooien, DB_CONFIG er neerzetten en slapadd -l backup.ldif alles weer terug zetten, uiteraard met slapd gestopt)

een beetje standaard DB_CONFIG heeft bijvoorbeeld dit:

code:

set_cachesize   0       52428800        0

verder in je slapd.conf nogal van belang: checkpointing:

code:

directory       "/var/db/openldap-data"
checkpoint      128     15

checkpointing is een redelijk belangrijk ding voor de DB backend van OpenLDAP. Verder is BDB 4.2 de meest betrouwbare versie voor gebruik met OpenLDAP, niet de nieuwere 4.3 en 4.4 versies.