Weekly restart required; bind, slapd problem?

[YakkoWarner]

About once a week, I find the Zimbra server stops accepting IMAP connections (the only connection type I use), and I have to restart the Zimbra service (/etc/init.d/zimbra restart) to bring it back up.

It happened today, so I went through zimbra.log and found this:

Jul 23 16:25:08 cumorah zimbramon[1897]: 1897:info: Starting services initiated by zmcontrol
Jul 23 16:25:08 cumorah slapd[1944]: @(#) $OpenLDAP: slapd 2.4.23 (Mar  4 2011 19:32:07) $#012#011root@zre-debian5-64.eng.vmware.com:/home/build/p4/HELIX/ThirdParty/openldap/openldap-2.4.23.6z/servers/slapd
Jul 23 16:25:08 cumorah slapd[1944]: daemon: bind(7) failed errno=99 (Cannot assign requested address)
Jul 23 16:25:08 cumorah slapd[1944]: slapd stopped.
Jul 23 16:25:08 cumorah slapd[1944]: connections_destroy: nothing to destroy.
Jul 23 16:25:13 cumorah slapd[1947]: @(#) $OpenLDAP: slapd 2.4.23 (Mar  4 2011 19:32:07) $#012#011root@zre-debian5-64.eng.vmware.com:/home/build/p4/HELIX/ThirdParty/openldap/openldap-2.4.23.6z/servers/slapd
Jul 23 16:25:13 cumorah slapd[1947]: daemon: bind(7) failed errno=99 (Cannot assign requested address)
Jul 23 16:25:13 cumorah slapd[1947]: slapd stopped.
Jul 23 16:25:13 cumorah slapd[1947]: connections_destroy: nothing to destroy.

(this repeats several times, and then...)

Jul 23 16:25:43 cumorah slapd[1964]: @(#) $OpenLDAP: slapd 2.4.23 (Mar  4 2011 19:32:07) $#012#011root@zre-debian5-64.eng.vmware.com:/home/build/p4/HELIX/ThirdParty/openldap/openldap-2.4.23.6z/servers/slapd
Jul 23 16:25:43 cumorah slapd[1964]: daemon: bind(7) failed errno=99 (Cannot assign requested address)
Jul 23 16:25:43 cumorah slapd[1964]: slapd stopped.
Jul 23 16:25:43 cumorah slapd[1964]: connections_destroy: nothing to destroy.
Jul 23 16:25:55 cumorah sshd[1861]: Received signal 15; terminating.
Jul 23 16:25:55 cumorah sshd[2008]: Server listening on :: port 22.
Jul 23 16:25:55 cumorah sshd[2008]: Server listening on 0.0.0.0 port 22.
Jul 23 16:26:06 cumorah zmmailboxdmgr[2235]: status requested
Jul 23 16:26:06 cumorah zmmailboxdmgr[2235]: stale pid 28059 found in /opt/zimbra/log/zmmailboxd_manager.pid: No such process
Jul 23 16:26:06 cumorah zmmailboxdmgr[2235]: assuming no other instance is running
Jul 23 16:26:06 cumorah zmmailboxdmgr[2235]: file /opt/zimbra/log/zmmailboxd.pid does not exist
Jul 23 16:26:06 cumorah zmmailboxdmgr[2235]: assuming no other instance is running
Jul 23 16:26:06 cumorah zmmailboxdmgr[2235]: no manager process is running
Jul 23 16:28:05 cumorah zmmailboxdmgr[2568]: status requested
Jul 23 16:28:05 cumorah zmmailboxdmgr[2568]: stale pid 28059 found in /opt/zimbra/log/zmmailboxd_manager.pid: No such process
Jul 23 16:28:05 cumorah zmmailboxdmgr[2568]: assuming no other instance is running
Jul 23 16:28:05 cumorah zmmailboxdmgr[2568]: file /opt/zimbra/log/zmmailboxd.pid does not exist
Jul 23 16:28:05 cumorah zmmailboxdmgr[2568]: assuming no other instance is running
Jul 23 16:28:05 cumorah zmmailboxdmgr[2568]: no manager process is running
Jul 23 16:30:01 cumorah postfix/postqueue[2712]: fatal: Queue report unavailable - mail system is down
Jul 23 16:30:01 cumorah zimbramon[2692]: 2692:info: 2011-07-23 16:30:01, QUEUE: 0 0

What's wrong here?

[phoenix]

That error usually indicates there's something already running on port 389 or possible a hosts file error. Go to the Split DNS article and, just for confirmation, run all the commands in the 'Verify...' section of that article.

[YakkoWarner]

Ok, I'll see if the dnsmasq option works. I made the change; I guess I'll find out in a week if it spontaneously quits again.

It does beg the question, though: why does it care? It's obviously capable of running correctly for several days before realizing something's not expected; so what triggers this occasional check and refusal to accept things the way they are?

[YakkoWarner]

Originally Posted by YakkoWarner

Ok, I'll see if the dnsmasq option works. I made the change; I guess I'll find out in a week if it spontaneously quits again.

The first network hiccup caused the DHCP client to refresh its name servers back to the original, bypassing dnsmasq. I know there's a way to have DHCP update dnsmasq's config instead of resolv.conf directly, but fortunately my network setup is static, so I forced my network config to always use 127.0.0.1 (dnsmasq) as the name server, and it's been working fine since.