action #78064
closedfailing logrotate on monitor.qa.suse.de due to mariadb/mysql?
0%
Description
Observation¶
On monitor.qa.suse.de systemctl --failed
shows that logrotate fails, `systemctl status logrotate shows:
● logrotate.service - Rotate log files
Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2020-11-16 00:00:07 CET; 22h ago
Docs: man:logrotate(8)
man:logrotate.conf(5)
Main PID: 6561 (code=exited, status=1/FAILURE)
Nov 16 00:00:07 openqa-monitor logrotate[6561]: [61B blob data]
Nov 16 00:00:07 openqa-monitor logrotate[6561]: error: 'Access denied for user 'root'@'localhost>
Nov 16 00:00:07 openqa-monitor logrotate[6561]: /etc/logrotate.d/mariadb failed, probably because
Nov 16 00:00:07 openqa-monitor logrotate[6561]: the root acount is protected by password.
Nov 16 00:00:07 openqa-monitor logrotate[6561]: See comments in /etc/logrotate.d/mariadb on how >
Nov 16 00:00:07 openqa-monitor logrotate[6561]: error: error running non-shared postrotate scrip>
Nov 16 00:00:07 openqa-monitor systemd[1]: logrotate.service: Main process exited, code=exited, >
Nov 16 00:00:07 openqa-monitor systemd[1]: Failed to start Rotate log files.
Nov 16 00:00:07 openqa-monitor systemd[1]: logrotate.service: Unit entered failed state.
Nov 16 00:00:07 openqa-monitor systemd[1]: logrotate.service: Failed with result 'exit-code'.
I wonder what we even use mariadb for. lsof -p $pid_of_mysql
showed a lot of /var/lib/mysql/icinga2_director . I assume this is old and unused?
grep -iR icinga /etc/apache2 /etc/nginx
showed /etc/nginx/vhosts.d/01-icingaweb2.conf
which reveals that http://icinga.qa.suse.de/ is the relevant domain which actually resolves but yields "502 Bad Gateway".
Suggestions¶
- Find out if we need that
- If no, delete packages like icinga2, mariadb, mysql, etc. , and see if logrotate works again
- If yes, fix logrotate access
Updated by okurz about 4 years ago
- Due date set to 2020-11-24
- Status changed from Workable to Feedback
- Assignee set to okurz
asked nsinger in chat
Updated by okurz about 4 years ago
- Status changed from Feedback to Resolved
he said that likely not needed, I could check existing database content. With sudo -u mysql mysql
and the SQL command show databases;
I found only a "test" database so likely we can easily remove everything here :) I did that now and so I would not expect logrotate to fail on mariadb/mysql anymore.
Updated by okurz over 3 years ago
- Related to action #93195: [Alerting] Failed systemd services alert (except openqa.suse.de) on 2021-05-28, logrotate.service on openqaworker-arm-1 added