/etc/cron.daily/logrotate:
error: error running shared postrotate script for '/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/error.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1
Description
Description
Event Timeline
Comment Actions
I tried creating a specific GRANT in the database for the debian user as specified in some Debian docs..
User: debian-sys-maint
Config file: /etc/mysql/debian.cnf
Grant: mysql> GRANT RELOAD, SHUTDOWN, PROCESS, SHOW DATABASES, SUPER, LOCK TABLES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY PASSWORD 'XXXXX';
I executed the logrotate script by hand with no errors, however again today same cronspam. Any other idea?
I'm tempted to just 2>/dev/null the logrotate daily cronjob.
Comment Actions
As far as I know, nothing running on that host still uses mysql. If that's right, then the solution is obvious :)
Comment Actions
Ah, I'm wrong, nova still uses a local database. So, to restate: We should move everything currently using local mysql there to m5, then we can uninstall mysql and this issue will go away :)
Comment Actions
Does this mean merging nova in both deployments? There is already a nova database in m5, in use by the main deployment. Could they share the the DB as keystone/glance do?
Comment Actions
The GRANT was wrong, it needs to be IDENTIFIED BY 'xxxx' instead of IDENTIFIED BY PASSWORD (this last one expects a hashed password).
Now, if I execute aborrero@cloudcontrol1003:~ 6s $ sudo /usr/sbin/logrotate --verbose -f /etc/logrotate.conf the return code is 0, in both cloudcontrol1003.wikimedia.org and cloudcontrol1004.wikimedia.org.
Comment Actions
Does this mean merging nova in both deployments?
No, it shouldn't be merged. We'll need a new nova database (like nova-eqiad1 or nova1 or something) so that the systems are separate. It should still be on m5 though since that's were prod databases go. Everything else is there already, right?