LP #1025536: Logrotate script check after rotate

It appears that this issue is no longer being worked on, so we are closing it for housekeeping purposes. If you believe the issue still exists, please open a new ticket after confirming it's present in the latest release.

The issue still exists.

**Comment from Launchpad by: Nilnandan Joshi on: 11-08-2014 08:45:45

Checked the same in mysql-log-rotate.sh for PXC 5.5 and PXC 5.6

@localstatedir@/mysqld.log {

1. create 600 mysql mysql
   notifempty
   daily
   rotate 3
   missingok
   compress
   postrotate
   # just if mysqld is really running
   if test -x @bindir@/mysqladmin && \ @bindir@/mysqladmin ping &>/dev/null
   then
   @bindir@/mysqladmin flush-logs
   fi
   endscript
   }

**Comment from Launchpad by: Valerii Kravchuk on: 10-09-2012 11:11:29

In both current 5.1 and 5.5 branches of percona-server mysql-log-rotate script looks like the following:

...
/home/openxs/dbs/p5.5/data/mysqld.log {

1. create 600 mysql mysql
   notifempty
   daily
   rotate 3
   missingok
   compress
   postrotate

2. just if mysqld is really running
   if test -x /home/openxs/dbs/p5.5/bin/mysqladmin && \ /home/openxs/dbs/p5.5/bin/mysqladmin ping &>/dev/null
   then
   /home/openxs/dbs/p5.5/bin/mysqladmin flush-logs
   fi
   endscript
   }

So, no prerotate checks are made and some of concerns expressed in the last comment looks still valid.

**Comment from Launchpad by: Volans on: 19-07-2012 09:19:35

The logic is fine, but the script uses mysqladmin to flush logs so is possible that the mysqladmin binary is missing or not anymore executable while mysqld is running. In this case the script will rotate logs without flushing and will be no error message about this corner case situation in /var/log/messages.

For this reason I suggested to move some sanity checks to the prerotate, like this one:

test -x /usr/bin/mysqladmin || exit 0

Changing also the "exit 0" with another exit value in order to log into /var/log/messages the error.

Maybe I'm wrong, but it seems to me that the script can handle the following situations:
1) Mysqladmin ping is OK => flush logs
2) Mysqladmin ping is KO AND no running process => exit 1
3) Mysqladmin ping is KO AND there is a running process => exit 0

I think that the case (2) should exit with a 0 value, because in this case simply MySQL was stopped and I don't see any reason to log into messages this as an error. I suspect that the check "if ps cax | grep -q mysqld; then" is wrong, because the exit value of grep in this case is "0" if a mysqld process exists and "1" if it not exists.

For the same reason the case (3) should have an exit status > 0 because this is a problem.

Also the grep check is unsafe, can match many other processes, I suggest to use:

pgrep '^mysqld$'

for a safer check.

Moreover I strongly suggest to add the directive "notifempty" to the logrotate script in order to avoid useless rotation of empty log files that can quickly lead to a lost of the useful ones due to the daily rotation directive. (why not weekly?)