On Tue, Oct 28, 2008 at 8:10 PM, Gonçalo Borges <[log in to unmask]> wrote:
> 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.
Without understanding the details there's a related bug.
https://savannah.cern.ch/bugs/?43300
https://gus.fzk.de/ws/ticket_info.php?ticket=42838
>
> 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
>
--
Steve Traylen
|