Hi, ich habe hier auf einem PC einen Cronjob für logrotate: @reboot root /usr/bin/systemctl start logrotate Der macht, soweit ich sehen kann, was er soll (apache-Logs werden korrekt rotiert, das sind die wichtigsten..., aber auch apcupsd, mysql) Da ich bei diesem Cronjob die Mails an root (noch) nicht unterdrücke, erhalte ich dann folgende Mail: "Job for logrotate.service failed because the control process exited with error code. See "systemctl status logrotate.service" and "journalctl -xe" for details." Bei journalctl -xe kommt das Wort "logrotate" nicht mal vor und in systemctl status logrotate steht: logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled) Active: inactive (dead) since Thu 2022-09-22 00:00:05 CEST; 7h ago Docs: man:logrotate(8) man:logrotate.conf(5) Process: 17374 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=0/SUCCESS) Main PID: 17374 (code=exited, status=0/SUCCESS) Sep 22 00:00:00 linux systemd[1]: Starting Rotate log files... Sep 22 00:00:05 linux systemd[1]: Started Rotate log files. was für mich ok aussieht. Warum nennt der Systemd das aber "failed with error code" wenn er im Status dann "status=0/SUCCESS" ausgibt? Nicht, dass ich das nicht gut ignorieren könnte, aber das passt doch nicht zusammen? Ach ja, das hier ist leap 15.1 und in /etc/logrotate.conf stehen die Systemvorgabewerte, keinerlei Besonderheiten, lediglich die /etc/logrotate.de/apache2 ist verändert, aber die tut ja, was sie soll... So richtig mein Freund wird Systemd wohl nie werden ;-) -- cu jth
Vielleicht war das in 15.1 noch anders, aber hier in 15.3 wird logrotate durch einen systemd-Timer gesteuert, und wenn man dessen Status abfragt, sieht der vernünftig aus. Allerdings tauchen in beiden Statusabfragen Zeilen mit 'Trigger' auf. Stammt der Cronjob denn von dir oder ist der bei der Installation entstanden? Es müsste mal einer mit funktionierendem logrotate in OS 15.1 nachsehen, wie das da geregelt wurde. 8:43:31 root@m1 /root $ systemctl status logrotate.timer ● logrotate.timer - Daily rotation of log files Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled) Active: active (waiting) since Fri 2022-09-16 17:53:05 CEST; 6 days ago Trigger: Fri 2022-09-23 00:00:00 CEST; 5h 16min left Triggers: ● logrotate.service Docs: man:logrotate(8) man:logrotate.conf(5) Sep 16 17:53:05 m1 systemd[1]: Started Daily rotation of log files. 18:43:35 root@m1 /root $ systemctl status logrotate.service ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static) Active: inactive (dead) since Thu 2022-09-22 18:37:14 CEST; 6min ago TriggeredBy: ● logrotate.timer Docs: man:logrotate(8) man:logrotate.conf(5) Process: 16083 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=0/SUCCESS) Main PID: 16083 (code=exited, status=0/SUCCESS) Sep 22 18:37:11 m1 systemd[1]: Starting Rotate log files... Sep 22 18:37:14 m1 systemd[1]: logrotate.service: Succeeded. Sep 22 18:37:14 m1 systemd[1]: Finished Rotate log files. -- Viele Grüße Michael
Am 22.09.22 um 18:53 schrieb Michael Behrens:
Hi, der crontab-Eintrag ist von mir, kann sein, das System startet den selbst auch noch mal, aber dann weiß ich nicht so recht, wie, denn in Yast/System/Services steht er auf "manuell". Aber im Status steht immer was von Null Uhr und @reboot ist bei mir ca. 22:37... Aber das Resultat ist ja das gleiche, auch wenn ich jetzt manuell "ystemctl start logrotate" aufrufe, steht im Status das gleiche... was ich nirgendwo habe, ist "Finished Rotate log files.", aber es wird definitiv erledigt. Vielleicht verursacht da eine der Configs in /etc/logrotate.d einen Fehler, der aber nicht angezeigt wird. Ich werde das mal verbose schalten, vielleicht kommt da was. Ansonsten, ist nicht so wichtig, dass hier jemand in "altem Kram" rumsuchen sollte, der 15.1 ja schon ist... -- cu jth
Hallo Jörg, mit systemctl list-timers --all bekommst du eine Liste, welche Service-Units timergesteuert ausgeführt werden. In der Liste ist dann der Zeitpunkt der nächsten Ausführung und der Zeitpunkt der letzten Ausführung enthalten.. Da sollte dann ein Eintrag für Logrotate zu finden sein. Möglicherweise kommen sich der timer-gesteuerte und der cron-gesteuerte Logrotate ins Gehege Du kannst den File logrotate.timer nach /etc/systemd/system kopieren, den Zeitpunkt im File ändern und mit systemctl reenable --now logrotate.timer aktualisieren und mit dem obigen Kommando noch mal kontrollieren. Statt reenable könnte auch enable notwendig sein. Wenn der Zeitpunkt kurz vor dem Reboot liegt, führt systemd solche Timer sofort nach dem reboot aus. Ich hab meine Cron-Aufgaben (automatisches Update und Backups) nach Systemd umgestellt und meine Timer-Units werden im Yast als manuell ausgeführt angezeigt. VG Joachim Am 23.09.22 um 07:37 schrieb Jörg Thümmler:
Am 23.09.22 um 10:31 schrieb Joachim Weber:
Hallo und Danke, das war der Schubs in die richtige Richtung: in /etc/systemd/system/timers.target.wants findet man einen Link auf /usr/lib/systemd/system/logrotate.timer und daraus ergibt sich, dass logrotate täglich zur Geisterstunde durch die Logs rotiert ;-) An sich nicht unlogisch... ich werd' ihn da nicht mehr stören Danke! -- cu jth
Vielleicht war das in 15.1 noch anders, aber hier in 15.3 wird logrotate durch einen systemd-Timer gesteuert, und wenn man dessen Status abfragt, sieht der vernünftig aus. Allerdings tauchen in beiden Statusabfragen Zeilen mit 'Trigger' auf. Stammt der Cronjob denn von dir oder ist der bei der Installation entstanden? Es müsste mal einer mit funktionierendem logrotate in OS 15.1 nachsehen, wie das da geregelt wurde. 8:43:31 root@m1 /root $ systemctl status logrotate.timer ● logrotate.timer - Daily rotation of log files Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled) Active: active (waiting) since Fri 2022-09-16 17:53:05 CEST; 6 days ago Trigger: Fri 2022-09-23 00:00:00 CEST; 5h 16min left Triggers: ● logrotate.service Docs: man:logrotate(8) man:logrotate.conf(5) Sep 16 17:53:05 m1 systemd[1]: Started Daily rotation of log files. 18:43:35 root@m1 /root $ systemctl status logrotate.service ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static) Active: inactive (dead) since Thu 2022-09-22 18:37:14 CEST; 6min ago TriggeredBy: ● logrotate.timer Docs: man:logrotate(8) man:logrotate.conf(5) Process: 16083 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=0/SUCCESS) Main PID: 16083 (code=exited, status=0/SUCCESS) Sep 22 18:37:11 m1 systemd[1]: Starting Rotate log files... Sep 22 18:37:14 m1 systemd[1]: logrotate.service: Succeeded. Sep 22 18:37:14 m1 systemd[1]: Finished Rotate log files. -- Viele Grüße Michael
Am 22.09.22 um 18:53 schrieb Michael Behrens:
Hi, der crontab-Eintrag ist von mir, kann sein, das System startet den selbst auch noch mal, aber dann weiß ich nicht so recht, wie, denn in Yast/System/Services steht er auf "manuell". Aber im Status steht immer was von Null Uhr und @reboot ist bei mir ca. 22:37... Aber das Resultat ist ja das gleiche, auch wenn ich jetzt manuell "ystemctl start logrotate" aufrufe, steht im Status das gleiche... was ich nirgendwo habe, ist "Finished Rotate log files.", aber es wird definitiv erledigt. Vielleicht verursacht da eine der Configs in /etc/logrotate.d einen Fehler, der aber nicht angezeigt wird. Ich werde das mal verbose schalten, vielleicht kommt da was. Ansonsten, ist nicht so wichtig, dass hier jemand in "altem Kram" rumsuchen sollte, der 15.1 ja schon ist... -- cu jth
Hallo Jörg, mit systemctl list-timers --all bekommst du eine Liste, welche Service-Units timergesteuert ausgeführt werden. In der Liste ist dann der Zeitpunkt der nächsten Ausführung und der Zeitpunkt der letzten Ausführung enthalten.. Da sollte dann ein Eintrag für Logrotate zu finden sein. Möglicherweise kommen sich der timer-gesteuerte und der cron-gesteuerte Logrotate ins Gehege Du kannst den File logrotate.timer nach /etc/systemd/system kopieren, den Zeitpunkt im File ändern und mit systemctl reenable --now logrotate.timer aktualisieren und mit dem obigen Kommando noch mal kontrollieren. Statt reenable könnte auch enable notwendig sein. Wenn der Zeitpunkt kurz vor dem Reboot liegt, führt systemd solche Timer sofort nach dem reboot aus. Ich hab meine Cron-Aufgaben (automatisches Update und Backups) nach Systemd umgestellt und meine Timer-Units werden im Yast als manuell ausgeführt angezeigt. VG Joachim Am 23.09.22 um 07:37 schrieb Jörg Thümmler:
Am 23.09.22 um 10:31 schrieb Joachim Weber:
Hallo und Danke, das war der Schubs in die richtige Richtung: in /etc/systemd/system/timers.target.wants findet man einen Link auf /usr/lib/systemd/system/logrotate.timer und daraus ergibt sich, dass logrotate täglich zur Geisterstunde durch die Logs rotiert ;-) An sich nicht unlogisch... ich werd' ihn da nicht mehr stören Danke! -- cu jth
participants (3)
-
Joachim Weber -
Jörg Thümmler -
Michael Behrens