I don't see any errors - looks like the admin server is starting up? If you do a service dirsrv-admin start or restart (while the directory server is running) do you get an error? Does ps -ef|grep httpd show 3 processes? I'm sorry that I was not more clear. Nsslapd seems to only be listening on ipv6 so the admin server never starts. After rebooting the server I ran service dirsrv start. Running service dirsrv-admin start resulted in Starting dirsrv-admin: appearing on the screen with no 'OK' for at least an hour, after which I cancelled the command with ^z. Subsequent investigations led me to believe that the cause was nsslapd only listening on ipv6. From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Wednesday, January 19, 2011 1:52 PM To: Ellsworth, Josh Subject: Re: slapd only listening on IPv6 On 01/19/2011 10:23 AM, Ellsworth, Josh wrote: OK, I think I have all of these answered. Can you post the error log from /var/log/dirsrv/admin-serv/error? [Tue Jan 18 16:28:40 2011] [info] done Init: Initializing NSS library [Tue Jan 18 16:28:40 2011] [debug] mod_admserv/mod_admserv.c(220): HashTableEnumerate: Key=admin-serv Val=cn=admin-serv-ldaptest,cn=389 Administration Server,cn=Server Group,cn=ldaptest.illuminatics.local,ou=illuminatics.local,o=NetscapeRoo t [Tue Jan 18 16:28:40 2011] [debug] mod_admserv/mod_admserv.c(1444): populate_tasks_from_server(): getting tasks for server [admin-serv] siedn [cn=admin-serv-ldaptest,cn=389 Administration Server,cn=Server Group,cn=ldaptest.illuminatics.local,ou=illuminatics.local,o=NetscapeRoo t] [Tue Jan 18 16:28:40 2011] [notice] Access Host filter is: *.illuminatics.local [Tue Jan 18 16:28:40 2011] [notice] Access Address filter is: * [Tue Jan 18 16:28:40 2011] [error] NSS_Shutdown failed: -8038 [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module authz_host_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module auth_basic_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module authn_file_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module log_config_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module env_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module mime_magic_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module expires_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module deflate_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module headers_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module unique_id_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module setenvif_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module mime_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module vhost_alias_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module negotiation_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module dir_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module actions_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module alias_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module rewrite_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module cache_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module disk_cache_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module cgi_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module restartd_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module nss_module [Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module admserv_module [Tue Jan 18 16:28:40 2011] [debug] mod_admserv/mod_admserv.c(2501): [1792] create_server_config [0xbogus %p for (null) [Tue Jan 18 16:28:40 2011] [debug] mod_admserv/mod_admserv.c(2489): [1792] create_config [0xbogus %p for (null) [Tue Jan 18 16:28:40 2011] [info] done Init: Initializing NSS library [Tue Jan 18 16:28:41 2011] [notice] Apache/2.2 configured -- resuming normal operations [Tue Jan 18 16:37:59 2011] [warn] child process 1797 still did not exit, sending a SIGTERM [Tue Jan 18 16:38:00 2011] [notice] caught SIGTERM, shutting do What platform? [root at ldaptest ~]# uname -a Linux ldaptest 2.6.18-194.17.4.el5xen #1 SMP Mon Oct 25 16:36:31 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux What versions of 389-ds-base and 389-admin? [root at ldaptest ~]# yum list | grep 389 389-admin.x86_64 1.1.13-1.el5 installed 389-admin.x86_64 1.1.14-1.el5 installed 389-admin-console.noarch 1.1.5-1.el5 installed 389-admin-console-doc.noarch 1.1.5-1.el5 installed 389-adminutil.x86_64 1.1.8-4.el5 installed 389-adminutil.x86_64 1.1.13-1.el5 installed 389-console.noarch 1.1.4-1.el5 installed 389-ds.noarch 1.2.1-1.el5 installed 389-ds-base.x86_64 1.2.7.5-1.el5 installed 389-ds-console.noarch 1.2.3-1.el5 installed 389-ds-console-doc.noarch 1.2.3-1.el5 installed 389-dsgw.x86_64 1.1.5-1.el5 installed 389-dsgw.x86_64 1.1.6-1.el5 installed Running 'grep nsslapd-listenhost /etc/dirsrv/slapd-INSTANCENAME/dse.ldif' (with no quotes of course) does not return anything. I don't see any errors - looks like the admin server is starting up? If you do a service dirsrv-admin start or restart (while the directory server is running) do you get an error? Does ps -ef|grep httpd show 3 processes? From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Wednesday, January 19, 2011 10:32 AM To: General discussion list for the 389 Directory server project. Cc: Ellsworth, Josh Subject: Re: slapd only listening on IPv6 On 01/19/2011 07:11 AM, Ellsworth, Josh wrote: I am working on a test 389DS instance and yesterday it started giving me trouble. The admin server would not start up correctly. Can you post the error log from /var/log/dirsrv/admin-serv/error? What platform? What versions of 389-ds-base and 389-admin? I think that the problem is because slapd is not listening on IPv4. grep nsslapd-listenhost /etc/dirsrv/slapd-INSTANCENAME/dse.ldif [root at ldaptest ~]# netstat -aunt Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 :::389 :::* LISTEN tcp 0 0 :::22 :::* LISTEN tcp 0 0 :::636 :::* LISTEN tcp 0 0 ::ffff:192.168.115.100:22 ::ffff:192.168.150.117:1268 ESTABLISHED udp 0 0 0.0.0.0:867 0.0.0.0:* udp 0 0 0.0.0.0:870 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:111 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* udp 0 0 0.0.0.0:47870 0.0.0.0:* udp 0 0 :::35392 :::* udp 0 0 :::5353 :::* [root at ldaptest ~]# lsof -i COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME portmap 1084 rpc 3u IPv4 2955 UDP *:sunrpc portmap 1084 rpc 4u IPv4 2956 TCP *:sunrpc (LISTEN) rpc.statd 1115 rpcuser 3u IPv4 3072 UDP *:870 rpc.statd 1115 rpcuser 6u IPv4 3058 UDP *:867 rpc.statd 1115 rpcuser 7u IPv4 3075 TCP *:rsync (LISTEN) sshd 1385 root 3u IPv6 3955 TCP *:ssh (LISTEN) cupsd 1393 root 4u IPv4 3987 TCP localhost.localdomain:ipp (LISTEN) cupsd 1393 root 6u IPv4 3990 UDP *:ipp avahi-dae 1467 avahi 13u IPv4 4197 UDP *:mdns avahi-dae 1467 avahi 14u IPv6 4198 UDP *:mdns avahi-dae 1467 avahi 15u IPv4 4199 UDP *:47870 avahi-dae 1467 avahi 16u IPv6 4200 UDP *:35392 ns-slapd 1616 nobody 6u IPv6 4476 TCP *:ldap (LISTEN) ns-slapd 1616 nobody 7u IPv6 4477 TCP *:ldaps (LISTEN) Is there an easy way to fix this? Since it is a test server I _could_ wipe it and start over, but I don't want this to be a problem when we move to production. Thanks! Josh -- 389 users mailing list 389-users at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20110119/1048fe5c/attachment-0001.html
