I think I know why a few people here have problems ...
I experienced the same problem and started looking around, as it seems people with syslog are fine, people with rsyslog have problems, i tracked this down to (at least at my installation):
in /etc/logrotate.d/ is the file zimbra.
The first two entries are for the syslogs, here in the postrotate section, which does stuff like reloading the syslogd after logrotation, etc., i had (amongst other):
killall -HUP syslogd 2> /dev/null || true
since my system is using rsyslog instead of standard syslog it will never reload the syslog-deamon and therefore you have problems with the logfiles. This is even more problematic as zimbra begins with z and therefore it is the last script which gets executed from logrotate, if it would not be the last one, there would have been a chance that a later script reloads the syslog daemon :-) I changed this line to:
killall -HUP rsyslogd 2> /dev/null || true
(notice the r in front of rsyslogd)
And hopefully tomorrow will be all good!
I believe this is a bug from zimbra as the tool for installing the logging facility should check if the system uses syslogd or rsyslogd and change the configuration accordingly.
hope this helps anybody,
Yes, it worked out fine for me
Since I made these chances I do not have problems with the stats and status.
However, until now I did not file a bug, but you are right and I will do this now!
I'm glad my finding was useful for at least another person :-)
Created a patch in bugs, go voting :-)
there was already a bug in the bugtracking system. I created and added a patch for the zmsyslogsetup utility which would automatically detect and change the configuration from syslog to rsyslog where appropriate.
If this problem concerns you, please consider voting on this bug/patch as I am sure you don't want to take care of this on the next upgrade as well ;-)
Bug 43081 – Server statistics fail after logrotate with rsyslogd