Ajax web client login fails with "/service/soap/SearchRequest Failed to load"

Al-MacLean · Post by **Al-MacLean** » Thu Nov 05, 2015 9:13 am

Hi,
This morning we started experiencing web client logins failing with the Default/AJAX interface version, but only for some user accounts (which were fine yesterday).

Our Zimbra version is 8.6.0_GA_1178 (OSE) on Ubuntu server 14.04 LTS, with 16GB RAM, just 22 user accounts and 40 resource accounts. I am aware Zimbra Patch 4 is available - this is scheduled to be installed next week.

We have three user accounts (that I have been notified about) where the web client login appears to freeze at the "Loading" splash screen. The actual browser error reports as "/service/soap/SearchRequest Failed to load" - this message text as reported by Chrome.

We have tried waiting on the splash screen for over 3 minutes, but login does not complete (but examining the dev tools view for the browser, via F12, indicates the soap failure noted above).

If the user clicks the "HTML Version" link on the splash screen, the session then completes loading immediately (using the HTML version).

I initially tried rebooting the Zimbra server (after 34 days of uptime), but no improvement resulted.

I have tested that this is specific to only certain Zimbra user accounts by logging in at their PC within their local browser, but with my Zimbra account, which loads correctly and immediately. This simple test should eliminate the issue being related to the local PC, their Windows user profile, browser configuration, or a general server or network issue. Majority of users remain unaffected and login as normal.

The issue occurs whether it is the actual user on their own PC, or if I use the Administration GUI to "View Mail" on their account.

We have tested this issue with the same results on Firefox, Chrome and Internet Explorer.

I am not sure which would be the best log file to examine for further diagnostic info.
I have tried grepping for entries relating to one of the accounts with the issue within the following logs:-
/opt/zimbra/log/nginx.log, which has one entry indicating: "client prematurely closed connection, so upstream connection is closed too while SSL handshaking to upstream"

/opt/zimbra/log/access_log.2015-11-05, (as the issue only started today) which doesn't seem to indicate a problem (so far as my small knowledge can determine)

/opt/zimbra/log/mailbox.log, which does list entries for the soap/SearchRequest text, along with an "elapsed=n", where n varies from 0 upwards.

I would appreciate suggestions to possible remedy or areas to examine.

Thanks,
Alec

mantykora · Post by **mantykora** » Wed Nov 18, 2015 5:44 am

Got the same issue , Release 8.6.0.GA.1153.UBUNTU14.64 UBUNTU14_64 FOSS edition, Patch 8.6.0_P4. any hint ?

Al-MacLean · Post by **Al-MacLean** » Wed Nov 18, 2015 6:23 am

One of the users that experienced the trouble started suddenly working again after the weekend, without my making any changes - but the other two were still having the same problem.

I applied the Patch 4 update per our planned schedule, then did a server shutdown and restart - in fact, as I run Zimbra as a Hyper-V VM, I shut it down (including actual VM "power down" from the Hyper-V console), did a full VM file copy to our backup NAS, restarted it, stopped the zimbra services, then applied Patch 4, restarted the zimbra services, then did another server restart using "shutdown -r now", then finally verifying all services working and access was OK.

After that, all the users were connecting using the AJAX web login option successfully again. I also noticed that the mobile web client responded much more quickly - so I may plan in scheduled full restarts as part of our cron maintainance - perhaps once per week on a Sunday.

As part of nightly our backups, I stop and restart the Zimbra services stack, so I can only think that the full server restart made the difference (I can't rule out it being Patch 4 due to the sequence I followed, noted above) . I had previously tried a "reboot" type cycle prior to the Patch without it making any difference - also at that time the "htop" uptime indicated that the server had been up for 34 days prior to the "shutdown -r now" method of rebooting.

I'm not a Linux expert by a long-shot - and my recent research reading has indicated that "reboot" and "shutdown -r" may be slightly differently interpreted by the system, with "shutdown -r " being preferred for safe file and process handling.

mantykora · Post by **mantykora** » Wed Nov 18, 2015 6:54 am

Thank you , for detailed info. I'll do a "poweroff" restart tonight. I'll get back with the result.

mantykora · Post by **mantykora** » Thu Nov 19, 2015 3:21 am

Restart didn't help, but I've found what was cousing this issue on my server. There was shared calendar on problematic account from recently deleted user. After removing this nonexistet calendar (was strikethrough) in html interface, rich ajax works again.
Maybe you need to revoke all shared resources before deleting account.

Al-MacLean · Post by **Al-MacLean** » Thu Nov 19, 2015 4:05 am

Interesting - I'll check our list of calendars to see if that may have been involved.

Nice observation - and thanks for sharing your findings back here.