Dear All...

This is just an email for your knowledge (and for my future reference :) 
) regarding a problem I had after installing one of the last glite 
updates in one of my CEs.

The ldap server was not able to start. An "lsof -n | grep IPv4" showed 
that bdii-fwd was listening on port 2170 but slapd processes were not 
listening on ports 2171 and 2172.

Trying to run the slapd daemon manually with the proper debug bit mask I 
got:

---*---

[root@i2g-ce01 log]# /usr/sbin/slapd -d 2048 -f 
/opt/bdii/var/2172/bdii-slapd.conf -h ldap://localhost:2172 -u edguser
@(#) $OpenLDAP: slapd 2.2.13 (Nov 15 2007 12:10:40) $
   
 [log in to unmask]:/mnt/src/4/BUILD/openldap-2.2.13/openldap-2.2.13/build-servers/servers/slapd
bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)
bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)
/opt/bdii/var/2172/bdii-slapd.conf: line 11: schema checking disabled! 
your mileage may vary!
bdb_db_init: Initializing BDB database
bdb_db_init: Initializing BDB database
bdb(o=infosys): mmap: Cannot allocate memory
bdb_db_open: dbenv_open failed: Cannot allocate memory (12)
backend_startup: bi_db_open(1) failed! (12)
bdb(o=infosys): DB_ENV->lock_id_free interface requires an environment 
configured for the locking subsystem
bdb(o=infosys): txn_checkpoint interface requires an environment 
configured for the transaction subsystem
bdb_db_destroy: txn_checkpoint failed: Invalid argument (22)
slapd stopped.
connections_destroy: nothing to destroy.

---*---

I realized that this was a problem in allocating memory. Doing a strace 
to previous command "strace -f /usr/sbin/slapd -d 2048 -f 
/opt/bdii/var/2172/bdii-slapd.conf -h ldap://localhost:2172 -u edguser > 
/tmp/xxxx 2>&1" I saw that the problematic part was

---*---

(...)
stat64("/opt/bdii/var/2172/infosys/__db.002", {st_mode=S_IFREG|0600, 
st_size=1073741824, ...}) = 0
open("/opt/bdii/var/2172/infosys/__db.002", O_RDWR|O_CREAT|O_LARGEFILE, 
0600) = 9
fcntl64(9, F_SETFD, FD_CLOEXEC)         = 0
mmap2(NULL, 1073741824, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = -1 
ENOMEM (Cannot allocate memory)
write(2, "bdb(o=infosys): mmap: Cannot all"..., 45bdb(o=infosys): mmap: 
Cannot allocate memory) = 45
close(9)                                = 0
(...)

---*---

It seems there was a problem uploading to memory the 
/opt/bdii/var/2172/infosys/__db.002 db which has 1G (so high????). 
Comparing with my other CEs which were OK, the only difference between 
the machines was that they were using different kernels. The "good" CEs 
were the ones using the std SL kernel (2.6.9-78.0.1.ELsmp). My 
problematic CE was one of the last versions downloaded from kernel.org 
and compiled by myself. Therefore, I recompiled my kernel with the 
definitions of the std SL kernel (config-2.6.9-78.0.1.ELsmp)

After that, slapd daemons started correctly:

---*---
root@i2g-ce01 ~]# ps xua | grep slapd
edguser   4115  6.4  0.1 2124000 3448 ?      Ssl  19:05   0:04 
/usr/sbin/slapd -f /opt/bdii/var/2171/bdii-slapd.conf -h 
ldap://localhost:2171 -u edguser
edguser   4302  0.0  0.1 2123868 3204 ?      Ssl  19:06   0:00 
/usr/sbin/slapd -f /opt/bdii/var/2172/bdii-slapd.conf -h 
ldap://localhost:2172 -u edguser
root      4312  0.0  0.0  3732  620 pts/0    R+   19:06   0:00 grep slapd
---*---

So, it seems people using non standard kernels have to be aware of the 
parameters they pass to compile the kernel...

Cheers
Goncalo