Interesting message when trying to access server statistics:
"Server Error Encountered:"
Message: system failure: Unable to read logger stats Error code: service.FAILURE Method: [unknown] Details:soap:Receiver
So there's a SOAP server that might not be running. I just read a suggestion to restart zmloggerctl. I'm giving that a try.
Amazing how vexing a problem this seems to be for a lot of people!
SOAP is just the underlying AJAX system that Zimbra uses for the web client and admin GUI.
Check if there's anything in /var/log/zimbra.log that corresponds to the time you saw that error. Assuming, of course, that entries are being logged to zimbra.log.
Argh ... nothing logged in /var/log/zimbra.log since 8:40 a.m. yesterday. It gives the impression that something that I did in the process of trying to solve this problem broke the logging. I'm going to do a quick restart of the whole system ... and that had no effect.
I might be reduced to reading the source code.
Do you know (roughly? or specifically?) what you've done to troubleshoot since yesterday?
Looking through the logger page on the wiki, it seems like the Zimbra zmlogger, zmlogprocess, and zmstat services only pull info from the log files that are generated by syslog. In your case, it sounds like something broke communication with syslog (for the peanut gallery, Ubuntu switched to rsyslogd with version 9.10).
Can you post your rsyslogd.conf file?
I've gotten confused between rsyslog and sysklog.
At some point I thought I was supposed to be using the other, and I installed that to have it delete the other.
Now I seem to be left with an rsyslog config file, but running sysklog.
I'm going to fuss with it a bit and get back to you.
(Just to recap for those following along, while I may have made things worse, system statistics were never working. So I'm not in the position of having broken it with an update or a change. I've just been trying things to see if I can get it to work.)
Indeed that was the case, and reinstalling rsyslog restored logging to zimbra.log. But still no MTA stats, and server stats still "no data available."
Well, that's a start at least.
As far as the rsyslogd/syslogkd confusion, the rsyslogd man page has this to say, since rsyslogd is a fork of sysklogd:
Have you tried regenerating the SSH keys as described previously? Even though you're running a single-server installation, Zimbra still uses SSH keys for inter-process communication, meaning that if those were not generated properly it will just not work right.However, rsyslogd should be able to use a standard syslog.conf and act like the original syslogd. However, an original syslogd will not work correctly with a rsyslog-enhanced configuration file. At best, it will generate funny looking file names.
Code:sudo su - zimbra zmsshkeygen zmupdateauthkeys zmcontrol restart