Admin Console will not load

[Samg]

I have just upgraded from open source 4.5 to Network Edition v5.0.6 and I can login to mail accounts on the server but when I try to start the admin console it stays stuck on the loading screen.

url
https://mailsvr.*mydomain*.net:7071/zimbraAdmin/

Output form zimcontrol
[zimbra@mailsvr bin]$ ./zmcontrol -v
Release 5.0.6_GA_2314.RHEL4_20080522092131 RHEL4 NETWORK edition

[zimbra@mailsvr bin]$ ./zmcontrol status
Host mailsvr.*mydomain*.net
antispam Running
antivirus Running
ldap Running
logger Running
mailbox Running
mta Running
snmp Running
spell Running
stats Running

I can see no errors in the zimbra or systems logs, everything worked before the upgrade and users can login now with no problem. I have tried several browsers os x 10.5 Safari 3.1.1 and Firefox 2.0.0.14 and windows xp Firefox 2.0, The result is the same I enter my admin login and see quite a bit of activity on the status bar of the browser but the page never changes from the loading screen.

Any help with this would be greatly appreciated.

Sam

[rwc101010]

So, I'm seeing something similar on Admin console load on the exact same version of Zimbra, but running on CentOS 4 - 32bit.

Release 5.0.6_GA_2314.RHEL4_20080522092131 CentOS4 NETWORK edition

I too am using Mac OS 10.5, Firefox 2.0.0.14, and Safari 3.1.1 on the client side.

I've tracked some of the issue down to SLAPD, and have found that upon load of the administrative console, SLAPD jumps to 99% processor utilization on my server, and stays there for the entire load of the admin console. After about 3-5 minutes, the admin console loads, and SLAPD processor utilization drops to nothing.

Can you run a 'top' to see the top processes running on your server while you're loading the admin console? I'd love to see if this is a bug in the latest release, so it can be addressed by Zimbra support.

Robert

[jholder]

Can you clear your cache and try again? I did an upgrade from 4.5.11 to 5.0.6 yesterday, and hit something similar. Clearing the cache fixed it.

If it doesn't, can you install firebug, and try again. Look for errors in the FB console.

[rwc101010]

Well, clearing the cache again did decrease load time, but it still seems to take about a minute to come up on first load (I assume it's caching the newly loaded components, as it runs much faster after the initial load).

Interestingly, my SLAPD issue seems to have sorted itself out as well, though I'm not sure how that happened . . . more digging is needed, I guess

Robert

[rwc101010]

So, after doing a full cache flush in the browser, things did speed up a bit, but it was a temporary win.

I'm now able to correlate SLAPD processor utilization spikes, MTA failures to authenticate against the LDAP, and slow/failed loading of the Administrative web interface.

Following, are log and tool outputs pulled during a particularly ugly attempt to load the Administrative web interface - in fact, the interface never loaded on this try.

Excerpt from zimbra.log on my MTA server:

May 25 15:25:52 mta02 postfix/trivial-rewrite[6304]: warning: dict_ldap_lookup: Search error -5: Timed out 
May 25 15:25:52 mta02 postfix/trivial-rewrite[6304]: fatal: ldap:/opt/zimbra/conf/ldap-vmd.cf(0,lock|fold_fix): table lookup problem
May 25 15:25:53 mta02 postfix/master[5436]: warning: process /opt/zimbra/postfix/libexec/trivial-rewrite pid 6304 exit status 1

At the same time, I'm seeing SLAPD run at 99% processor utilization on an otherwise quiet machine:

(output of TOP on server running Zimbra's LDAP)

Top - 15:25:29 up 11 min,  1 user,  load average: 0.22, 0.28, 0.23
Tasks:  81 total,   2 running,  79 sleeping,   0 stopped,   0 zombie
Cpu(s): 27.0% us, 73.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   2075928k total,   698948k used,  1376980k free,    18524k buffers
Swap:  4096440k total,        0k used,  4096440k free,   193512k cached

  PID USER      PR  NI %CPU    TIME+  %MEM  VIRT  RES  SHR S COMMAND           
 3487 zimbra    18   0 98.9   0:21.98  1.4  261m  28m 4740 S slapd              
 5088 zimbra    20   0  1.0   0:19.80 14.0  917m 284m  38m S java               
    1 root      16   0  0.0   0:00.55  0.0  2644  548  468 S init               
    2 root      34  19  0.0   0:00.00  0.0     0    0    0 S ksoftirqd/0

I'm thinking we may have a bug with LDAP, that is causing cascading issues in services that rely on LDAP data connections...


Additional information on my install . . .
- This issue is (and these metrics pulled) from a freshly rebooted stack of servers - uptime between 10-15 minutes when the problem re-occurred.
- This server is running Release 5.0.6_GA_2314.RHEL4_20080522092131 CentOS4 NETWORK edition
- This server was upgraded from 4.5.10_GA last night without any install errors (install log available).
- Minor post install issues encountered with the MTA machine consistantly inheriting an incorrect value for the 'zimbraMtaAuthURL', even though LDAP value is correct (can provide more details, but may be an unrelated bug).

Robert

[Samg]

Well I have a bit more info on my problem and it is partially solved for now but the solution needs to be fixed. On our 4.5 installation I had enabled the Posix and Samba admin extensions "zimlets" Doing a bit of debugging in the browser it appeared that the admin console would hang when loading one of those extensions. I never really experienced a high server load it would just sit waiting and I let it sit for 15-20 min. After disabling both of those extensions the admin console finally came up.

I still get errors trying to use safari (known issue, several bug report in bug tracker) But Firefox works now. I used the firebug firefox extension to help track this down.

Safair at least works pretty well for the web client so far (a big improvment over ZCS4.5) but not on the admin console.

Now for the fun part I still need to get the posix and samba extensions working agin

Sam