(gelöst, aber wieder neu) exim paniclog mail loswerden

[michaa7]

Vor ein paar Tagen ist mein System out-of-RAM gelaufen. Nach einem Resett war alles ok, exim4 lief auch sofort wieder. Aber ich bekomme jetzt täglich diese paniclog Fehlermeldungsmail, die eben besagt dass kein memory allocated werden konnte, klar, war ja kein RAM mehr verfügbar.
In soweit gut dass root angemailt wurde, jetzt hätte ich gerne wieder Normalbetrieb ohne diese tägliche mail.
Kann ich das paniclog einfach löschen oder wie sonst sage ich exim dass ich das zur Kenntnis genommen habe und das log zu den Akten kann?

[rendegast]

README.Debian:

4.6. misc

* A non-empty paniclog is a nearly sure sign of bad things going on.
Thus, the cron job will send out warning messages to the syslog and
root if it finds the panic log non-empty. Please note that the
paniclog is not rotated daily, so existing issues will be reported
daily until either the paniclog is rotated due to its sheer size,
or you manually move it away, for example by calling logrotate -f
/etc/logrotate.d/exim4-paniclog from a shell.

[michaa7]

Leider klappt das so nicht. Ich bekam die letzten zwei tage trotz manuell und ohne fehlermeldung ausgeführtem
"logrotate -f /etc/logrotate.d/exim4-paniclog"
immer noch diese mails.

Woher stammt dieses Zitat?

README.Debian:
4.6. misc...

Wenn das daher ist
"zless /usr/share/doc/exim4-base/README.Debian.gz"
, dann schaut das bei mir (Debian/sid) anders aus:

4.6. misc

* convert4r4 is installed as /usr/sbin/exim_convert4r4.
* The charset for $header_foo expansions defaults to UTF-8 instead of
ISO-8859-1.
* [8]Marc Merlin's Exim 4 Page has a lot of ACL examples.
* For an example of Exim usage in a large installation, see Tony
Finch's [9]paper about the Exim installation at University of
Cambridge:

8. http://marc.merlins.org/linux/exim/
9. http://www-uxsup.csx.cam.ac.uk/~fanf2/h ... -eximconf/

Daraus schließe ich, dass sich da etwas geändert hat, nur was?

EDIT://
ich bin auf folgenden thread gestoßen:
http://debianforum.de/forum/viewtopic.php?f=32&t=142400
Dort auf folgendes kommando:
logrotate -d /etc/logrotate.conf

Was mir u.a. folgendes ausgibt:

rotating pattern: /var/log/exim4/paniclog 10485760 bytes (10 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/exim4/paniclog
log does not need rotating

Mit hatte das schon zuvor gestört, dass nach dem von dir (rendegast) geposteten README ein log unter /etc liegen sollte und nicht unter /var. Die logrotate config klärt das ja. Bliebe zu fragen, woher deinen README stammt.

Ich habe jetzt jedenfals erstmal folgendes ausgeführt:

"logrotate -f /var/log/exim4/paniclog"

Werde ich dann ja spätestens morgen wissen, ob das nun klappt.

EDIT://

Vermutlich ändert sich nichts, scheint ein lange existierender, ungefixter bug zu sein ...

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714910

Alledings ist auch ärgerlich, dass es bei "logrotate -f ..." überahuptkeine rückmeldung gibt

EDIT3://
Ok, mit der "-v" option erhält man ja zumindest infos was passiert, und das schein zu bestätigen, dass der buf biem forcierten logrotate immer noch besteht. Auch ist nun klar, warum ein file in /etc aufgerufen wird, das ist eben die configuration für das rotieren. so schaut das aus:

logrotate -f -v /etc/logrotate.d/exim4-paniclog
reading config file /etc/logrotate.d/exim4-paniclog

Handling 1 logs

rotating pattern: /var/log/exim4/paniclog forced from command line (10 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/exim4/paniclog
log does not need rotating

Die letzte zeile belegt wohl den bug ...

[rendegast]

Ich bekam die letzten zwei tage trotz manuell und ohne fehlermeldung ausgeführtem
"logrotate -f /etc/logrotate.d/exim4-paniclog"
immer noch diese mails.

Code: Alles auswählen

ls -l /var/log/exim4/paniclog

hat dann wohl immer noch Inhalt?
Einfach händisch leeren -> Länge 0.

Woher stammt dieses Zitat?

2.5. Miscellaneous packaging issues
2.5.1. The daily cron job
.....
* A non-empty paniclog is a nearly sure sign of bad things going on.
Thus, the cron job will send out warning messages

Sorry, wie da die "4.6" hineingekommen ist???

Ansonsten siehe mal nach "paniclog" resp. "PANICLOG" in
/etc/cron.daily/exim4-base
/etc/init.d/exim4
Ist kein Hexenwerk.

[michaa7]

Ich bekam die letzten zwei tage trotz manuell und ohne fehlermeldung ausgeführtem
"logrotate -f /etc/logrotate.d/exim4-paniclog"
immer noch diese mails.

Code: Alles auswählen

ls -l /var/log/exim4/paniclog

hat dann wohl immer noch Inhalt?
Einfach händisch leeren -> Länge 0.
...

Das ist ja genau was ich nicht will, ein log löschen. logrotate, so wie ich es verstehe, sollte ja genau dafür sorgen, dass ein (panic-) log nach einer vorgegebenen zeit *oder manuell per -f option* archiviert wird.

Mein bugreport war wohl in soweit erfolgreich, als der maintainer den bug mit v 3.8.7 geschlossen haben will, schaun mer mal ...

EDIT://
Hab mit logrotate v3.8.7-1 aus incoming geholt und installiert. Dem output nach tut es was es soll. Sollte also morgen nicht nochmal ne mail bekommen ...

Danke nochmal für den hinweis aus den manpages.

[Cae]

logrotate, so wie ich es verstehe, sollte ja genau dafür sorgen, dass ein (panic-) log nach einer vorgegebenen zeit

Oder auch nach Erreichen einer bestimmten Groesse. Wenn du mal in die /etc/logrotate.d/exim4-paniclog guckst, steht da

Code: Alles auswählen

/var/log/exim4/paniclog {
	size 10M
	missingok
	rotate 10
	compress
	delaycompress
	notifempty
	create 640 Debian-exim adm
}

-- aber nix von daily oder andere Zeitangaben. D.h. es wird grundsaetzlich nur bei 10 MB rotiert, sonst nicht.

Gruss Cae

[michaa7]

Gestern kam es auf meinem rechner zu einem lang anhaltenden freez (cpu +RAM 100%, keine reaktion mehr auf nichts, keine konsole, --> hard resett). Offenbar wollte zu diesem zeitpunkt exim4 etwas schreiben und hat keine ressourcen bekommen --> panic log --> benachrichtigungsemail heute beim neustart.

Wie ich das log rotiere ist klar, aber das kommando tut es wieder nicht:

# logrotate -fv /var/log/exim4/paniclog
Ignoring /var/log/exim4/paniclog because the file owner is wrong (should be root).

Handling 0 logs

Ownership ist tatsächlich nicht root.

# ls -la /var/log/exim4/paniclog
-rw-r----- 1 Debian-exim adm 88 Okt 3 19:11 /var/log/exim4/paniclog

Irgendetwas ist hier doch falsch, entweder die ownership wie sie vom exim maintainer gesetzt wurde oder die logrotate konfiguration. Jetzt will ich nicht gleich einen bugreport losschicken ohne zu verstehen ob ich damit auch wirklich richtig liege.

Aber ich möchte natürlich sowohl die tägliche warnmeldung loswerden als auch den bug gegen das richtige paket einreichen.

???

[michaa7]

zwei jahre später, gleiches problem:

Vermutlich während eines durch den Vivaldi-browser ausgelösten systemfreezes konnte exim keinen speicher anfordern:

2016-12-03 16:05:36 daemon: fork of queue-runner process failed: Cannot allocate memory

und daher bekam ich bein nächsten boot einen entsprechende systemmail. Aber wieder bekomme ich den fehler dass root keine rechte an der ensprechenden log datei hat:

# logrotate -fv /var/log/exim4/paniclog
Ignoring /var/log/exim4/paniclog because the file owner is wrong (should be root).

# ls -la /var/log/exim4/paniclog
-rw-r----- 1 Debian-exim adm 88 Dez 3 16:05 /var/log/exim4/paniclog

Das ist doch wohl ein bug? Ich meine logrotate sagt "should be root", aber der maintainer setzt die ownership auf Debian-exim / adm.