[SOLVED] zmmailboxdctl is not running.

[snowboarder04]

Just upgraded to 6.0 and changed IP's in the process - zmmailboxdctl refuses to start with the below prominent cause in the zmmailboxd.out log file:

Total time for which application threads were stopped: 0.0002360 seconds
Zimbra server reserving server socket port=110 bindaddr=94.193.*.* ssl=false
Fatal error: exception while binding to ports
java.net.BindException: Cannot assign requested address

I should like to strongly add that the 94.193.*.* address is the OLD IP address. We changed the IP by stopping the zimbra services (and ensuring there were no rogue processes still alive), then we changed the IP and then rebooted allowing zimbra to start up normally.

Following the reboot the service did not come back up at all and consistently presents the above error in the logs. The DNS has been updated to point to the new address so I *really* have no idea where it's getting the old IP address from.

There is an SSL certificate associated with the server (HTTPS/IMAPS), however we have changed IP before and this has not been a problem.

I've found the below thread which unfortunately is not much use, as the OP trails off on a tangent of attempting to recover data and not address the initial problem :/

Here's the output from various commands to save time:

[zimbra@zimbra ~]$ zmprov -l gs <mymailserver> | grep Bind
zimbraPop3BindAddress: 94.193.*.* (OLD IP)


[zimbra@zimbra ~]$ zmprov ms zimbra.bemail.co.uk zimbraPop3BindAddress 94.23.*.* (NEW IP)
[] INFO: I/O exception (java.net.ConnectException) caught when processing request: Connection refused
[] INFO: Retrying request
ERROR: zclient.IO_ERROR (invoke Connection refused, server: localhost) (cause: java.net.ConnectException Connection refused)

[zimbra@zimbra ~]$ cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
94.23.*.* <mymailserver> zimbra
127.0.0.1 localhost.localdomain localhost zimbra.bemail.co.uk zimbra
::1 localhost6.localdomain6 localhost6


Anyone got any suggestions? Right now we're email-less

[snowboarder04]

Solved it.

I reverted the IP back to the old one which let the zmmailboxdctl start up ok. Then I ran the following command to get the zimbraPop3BindAddress to bind to the new IP:

zmprov ms <mymailserver> zimbraPop3BindAddress 94.23.*.*

Then I stopped the services, changed the IP to the new IP and restarted the services. Lo-and-behold the zmmailboxdctl service started up ok and bound to the correct IP.

If you ask me, this is a bug, and a pretty glaring one at that. When I get some time I'll bugzilla it, but right now - it's sleep time!

[phoenix]

Originally Posted by snowboarder04

Solved it.

I reverted the IP back to the old one which let the zmmailboxdctl start up ok. Then I ran the following command to get the zimbraPop3BindAddress to bind to the new IP:

zmprov ms <mymailserver> zimbraPop3BindAddress 94.23.*.*

Then I stopped the services, changed the IP to the new IP and restarted the services. Lo-and-behold the zmmailboxdctl service started up ok and bound to the correct IP.

If you ask me, this is a bug, and a pretty glaring one at that. When I get some time I'll bugzilla it, but right now - it's sleep time!

Did you ever file this as a bug and if so, what is the bug number?

BTW, the hosts file you posted above is incorrect, it should read as follows (as per the documentation):

94.23.*.* <mymailserver> zimbra
127.0.0.1 localhost.localdomain localhost

[snowboarder04]

Originally Posted by phoenix

Did you ever file this as a bug and if so, what is the bug number?

BTW, the hosts file you posted above is incorrect, it should read as follows (as per the documentation):

94.23.*.* <mymailserver> zimbra
127.0.0.1 localhost.localdomain localhost

FYI, it looks like this has been brought up in this bug:
Bug 48129 &ndash; 6.0.7 upgrade failure, Could not bind to port=143

[phoenix]

Originally Posted by snowboarder04

FYI, it looks like this has been brought up in this bug:
Bug 48129 &ndash; 6.0.7 upgrade failure, Could not bind to port=143

No, it hasn't been raised in that bug report - the problems are not the same. The bug you mention was introduced in 6.0.7 and was specific to that release, it was fixed in 6.0.7.1.