Zimbra Forums

I recently upgrade Zimbra from 8.6.0 to 8.8.15 and then upgraded my server from Ubuntu 14.04 to 16.04 and then 18.04.

No issues during these upgrades. On zmcontrol start everything seems fine but on zmcontrol status Zimbra reports that logger is stopped and zmlogswatchctl is not running. As shown below.



I have tried the following reinstall van rsyslog



But the problem persists. Any suggestions on how this can be fixed?

Swatch is a perl program. Sometimes, a missing perl module that it requires is the reason for it not starting and aborting.

Look inside this file: /opt/zimbra/log/zmlogswatch.out for possible reason.

From the file /opt/zimbra/bin/zmlogswatchctl you should see something like this.

Where logfile=${zimbra_log_directory}/zmlogswatch.out

Here is an example of swatch running:

You can also run the command directly from the command line to see the possible reason it won't start.

or better yet...

And run one of the scripts present like this:

Ref: swatch allows one to use a simple config language - see /opt/zimbra/conf/swatchrc and then generates a perl program. That is the .swatchdog_script.XXXX. It looks for patterns in a logfile and then does actions when they are met.

HTH,

Jim

Everything looks fine. Swatch is running it seems...


I can run the script manually - no errors


Or run the script


What is strange is that there are many scripts in that directory

That is normal... It doesn't clean up after itself if it aborts or doesn't shutdown correctly. The only ones you need are the those listed in your ps output. The others you can delete as they are old. Those .swatchdog_script.20624 are generated from the swatchrc files where 20624 would be the pid in this example. You should have 2 swatchdog_scripts running when you do a ps.

When I run the script manually it starts without errors



But status remains down

When you started manually, you need to replicate what the script does including the pid files. zmlogswatchctl has the following lines that get executed when you are asking for status if it's running.

So you can manually do the following to see how/why zmlogswatchchtl might think programs it starts/stop isn't running.

The kill -0 construct from above is an odd way to determine if something is running. It doesn't send any signal and the kernel simply returns back a fail/success that you would be able to send a signal to that process if you have correct permissions. Most of the zimbra status scripts use this paradigm so that is why a lot of forum posts say to try and rm the pid file in case it existed with the wrong permissions and zimbra couldn't overwrite it. Note: what if pid's wrap and something else is running or if that pid file contains a low pid number and you have rebooted and one of the other programs now has that pid? Anyway...

start work like this. Note the amount of information that is saved in /var/log/zimbra.log

Normally, whenever something doesn't run from zmcontrol status - the first thing you do is something like:

zmcontrol [start|stop|restart|status] calls zmlogswatchctl with the same argument. If that fails to fix it, look at the pid files in /opt/zimbra/log for permission problems or tail -f /var/log/zimbra.log as you attempt to restart it and look for why.

HTH,

Jim