antispam stoppt nach einiger Zeit

[Sascha Pohl]

Hallo,

seit geraumer Zeit stelle ich fest, dass antispam irgendwann nicht mehr
läuft.
Wenn ich antispam starte läuft es erstmal wieder, aber irgendwann nach
mehreren Tagen ist es wieder gestoppt.
Seit wann das genau auftritt vermag ich nicht mehr zu sagen, ich denke,
es lag zeitlich mit der Umstellung auf systemd zusammen.

Viele Grüße
Sascha

[Juergen Edner]

Hallo Sascha,

dieses Verhalten kann ich bei mir nicht beobachten, auch höre ich das
erste Mal von einem stoppenden antispam-Dienst. Spontan fällt mir nur
ein, das Du sicherstellen solltest, dass der Rechner ausreichend
Speicher zur Verfügung hat. Ein Blick in die Logdatei wäre sicherlich
ebenfalls zu empfehlen.

Gruß Jürgen

--
Mail: jue...@eisfair.org

[Sascha Pohl]

Hallo Jürgen,

Am 05.10.2023 um 15:58 schrieb Juergen Edner:

> dieses Verhalten kann ich bei mir nicht beobachten, auch höre ich das
> erste Mal von einem stoppenden antispam-Dienst.

Ich habe das Forum verfolgt und mich auch gewundert, dass niemand
anderes das Problem zu haben scheint.

> ein, das Du sicherstellen solltest, dass der Rechner ausreichend
> Speicher zur Verfügung hat. Ein Blick in die Logdatei wäre sicherlich
> ebenfalls zu empfehlen.

Laut meminfo sollte eigentlich genug Speicher vorhanden sein. Ich werde
aber mal mehr Speicher zur Verfügung stellen und dann beobachten.
Der Logdatei kann ich nichts spezielles entnehmen. Dort fällt lediglich
auf, dass irgendwann keine Mails mehr untersucht werden.
Ein Fehler fällt mir dort allerdings auf: das rule update beendet sich
ständig mit "Update failed with error '3'!". Das scheint mir aber nicht
der Grund für die Beendigung des Dienstes zu sein.
Sollte ich mal den Debug-Modus aktivieren?

> Gruß Jürgen

Grüße
Sascha

[Juergen Edner]

Hallo Sascha,

> Ein Fehler fällt mir dort allerdings auf: das rule update beendet sich
> ständig mit "Update failed with error '3'!". Das scheint mir aber nicht
> der Grund für die Beendigung des Dienstes zu sein.
> Sollte ich mal den Debug-Modus aktivieren?

im Verzeichnis /var/antispam/spamassassin findest Du eine Datei mit
Namen sa-update.log, welche detaillierte Meldungen zum Update-Verlauf
und eventuell auftretendende Fehler beinhalten sollte.

[Alexander Dahl]

Moin,

Sascha Pohl schrieb Donnerstag, 5. Oktober 2023, 22:17 (CEST):
> Hallo Jürgen,
>
> Am 05.10.2023 um 15:58 schrieb Juergen Edner:
>
>> dieses Verhalten kann ich bei mir nicht beobachten, auch höre ich das
>> erste Mal von einem stoppenden antispam-Dienst.
> Ich habe das Forum verfolgt und mich auch gewundert, dass niemand
> anderes das Problem zu haben scheint.

Ich hab das bei antispam nach der Umstellung auf systemd auch sporadisch
festgestellt, konnte aber keine Regelmäßigkeit erkennen.

Bei stunnel hingegen, ist es sehr regelmäßig. Das steigt einmal pro
Woche aus, irgendwann in der Nach von Sonntag zu Montag. Leider führt
das dazu, dass irgendwann im Laufe des Montags fetchmail auch aufhört,
weil er die Postfächer, die über stunnel laufen, nicht mehr abholen
kann.

Ist aber hier in der Diskussion zu antispam off-topic. O:-)

Grüße
Alex

>
>> ein, das Du sicherstellen solltest, dass der Rechner ausreichend
>> Speicher zur Verfügung hat. Ein Blick in die Logdatei wäre sicherlich
>> ebenfalls zu empfehlen.
> Laut meminfo sollte eigentlich genug Speicher vorhanden sein. Ich werde
> aber mal mehr Speicher zur Verfügung stellen und dann beobachten.
> Der Logdatei kann ich nichts spezielles entnehmen. Dort fällt lediglich
> auf, dass irgendwann keine Mails mehr untersucht werden.
> Ein Fehler fällt mir dort allerdings auf: das rule update beendet sich
> ständig mit "Update failed with error '3'!". Das scheint mir aber nicht
> der Grund für die Beendigung des Dienstes zu sein.
> Sollte ich mal den Debug-Modus aktivieren?
>
>> Gruß Jürgen
>
> Grüße
> Sascha
>

--
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF 08FA 34AD CD00 7221 5CC6

[Marcus Röckrath]

Hallo Alexander,

Alexander Dahl wrote:

> Bei stunnel hingegen, ist es sehr regelmäßig. Das steigt einmal pro
> Woche aus, irgendwann in der Nach von Sonntag zu Montag.

Wird das Log wöchentlich rotiert?

Kann der Zeitpunkt des Austeigens auf die Zeit des Logrotierens eingegrenzt
werden?

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo zusammen,

Am 14.10.23 um 18:42 schrieb Alexander Dahl:

> Ich hab das bei antispam nach der Umstellung auf systemd auch sporadisch
> festgestellt, konnte aber keine Regelmäßigkeit erkennen.

ich hatte Ende März auf systemd umgestellt und direkt ein Speicherleck auf dem Eis. Dazu gibt es hier einen Thread "Speicherleck finden". Ich konnte die Ursache nicht wirklich finden. Letztendlich habe ich den Mailserver vom Fileserver getrennt und seitdem als eigenständige (virtuelle) Maschine laufen. Auf dem "Rest-Server" gab's seitdem keine Probleme mehr. Den Mailserver musste ich aber deutlich mit RAM aufrüsten (8GB) um der Sache halbwegs Herr zu werden. Vorher gab's Aussetzter wie z.B.

Jun 5 11:04:47 mail kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice,task=spamd child,pid=4033,uid=2022
Jun 5 11:04:47 mail kernel: Out of memory: Killed process 4033 (spamd child) total-vm:503352kB, anon-rss:405312kB, file-rss:0kB, shmem-rss:0kB, UID:2022 pgtables:1116kB oom_score_adj:0

Es wurde _immer_ spamd abgeschossen. Ob das die Ursache oder eine Auswirkung ist, kann ich nicht feststellen.

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

> ich hatte Ende März auf systemd umgestellt und direkt ein Speicherleck auf
> dem Eis. Dazu gibt es hier einen Thread "Speicherleck finden". Ich konnte
> die Ursache nicht wirklich finden.

Wenn du mal unter https://groups.google.com/g/spline.eisfair suchst, wirst
du ähnliche Speicherprobleme (inklusive oom-Killer) aus der Zeit vor
systemd finden; IMHO hat das auch nichts mit Systemd zu tun.

Kann du im Archiv bei Google mal nach oom-Kiler oder so suchen und schauen,
ob das dort auf einigen wenigen Maschinen aufgetretene Probleme mit deinem
vergleichbar ist?

Wenn der oom-Killer laufende Programme killt, muss das nicht der Verursacher
sein, sondern der Versuch des Kernels irgendwie wieder an Ram zu kommen.

--
Gruß Marcus
[eisfair-Team]

[Alexander Dahl]

Hallo zusammen,

Marcus Röckrath schrieb Samstag, 14. Oktober 2023, 19:10 (CEST):
> Alexander Dahl wrote:
>
>> Bei stunnel hingegen, ist es sehr regelmäßig. Das steigt einmal pro
>> Woche aus, irgendwann in der Nach von Sonntag zu Montag.
>
> Wird das Log wöchentlich rotiert?

Ja.

> Kann der Zeitpunkt des Austeigens auf die Zeit des Logrotierens eingegrenzt
> werden?

│fetchmail: sleeping at Sat, 14 Oct 2023 23:52:17 (CEST) for 1000 seconds
│fetchmail: stopping fetchmail-loader script

systemd sagt nicht, wann stunnel beendet wurde, nur "exited":

● stunnel.service
Loaded: loaded (/etc/init.d/stunnel; generated)
Active: active (exited) since Mon 2023-10-09 08:25:07 CEST; 1 week 0 days ago
Docs: man:systemd-sysv-generator(8)
Process: 23982 ExecStart=/etc/init.d/stunnel start (code=exited, status=0/SUCCESS)
CPU: 18.363s

Logging für stunnel sieht so aus:

STUNNEL_LOG_COUNT='6' # number of log files to save
STUNNEL_LOG_INTERVAL='weekly' # interval: daily, weekly, monthly

Die Datei /etc/logrotate.d/stunnel hat bei "postrotate" folgenden Aufruf
stehen:

/etc/init.d/stunnel --quiet restart

Wenn ich das von Hand auf der Konsole aufrufe ohne --quiet, funktioniert
das auch.

Wann genau logrotate seine weekly rotation macht? Keine Ahnung.

Grüße
Alex

[Holger Bruenjes]

Hallo Alex

Am 16/10/2023 um 09.56 schrieb Alexander Dahl:

> STUNNEL_LOG_COUNT='6' # number of log files to save
> STUNNEL_LOG_INTERVAL='weekly' # interval: daily, weekly, monthly
>
> Die Datei /etc/logrotate.d/stunnel hat bei "postrotate" folgenden Aufruf
> stehen:
>
> /etc/init.d/stunnel --quiet restart
>
> Wenn ich das von Hand auf der Konsole aufrufe ohne --quiet, funktioniert
> das auch.

Aender das mal in servcie


/usr/sbin/service --quiet restart stunnel

Holger

[Alexander Dahl]

Hallo Holger,

Hab ich mal in der logrotate config so eingetragen. Werde es
beobachten.

[Marcus Röckrath]

Hallo Alexander,

Alexander Dahl wrote:

>>> /etc/init.d/stunnel --quiet restart
>>>
>>> Wenn ich das von Hand auf der Konsole aufrufe ohne --quiet, funktioniert
>>> das auch.
>>
>> Aender das mal in servcie
>>
>> /usr/sbin/service --quiet restart stunnel
>
> Hab ich mal in der logrotate config so eingetragen. Werde es
> beobachten.

Gut, der Aufruf von init-Skripten wird ja auf systemd
mittels /etc/init.d/systemd_redirect umgeleitet, welches aus SuSE
"entliehen" ist.

Bei einer früheren Analyse dessen, was da passiert, war mir schon
aufgefallen, dass da ein zweiter Parameter nicht "durchgeht", also würde
oben statt

/etc/init.d/stunnel --quiet restart

dann wohl

/etc/init.d/stunnel --quiet

gemacht, was keinen Sinn macht.

Hier mal verschiedene Aufrufe für ntp:

eis64:/etc/init.d # /etc/init.d/ntp --quiet status
ntpd is running with Process ID(s) 10370 10368.


eis64:/etc/init.d # /etc/init.d/ntp status
● ntp.service
Loaded: loaded (/etc/init.d/ntp; generated)
Active: active (running) since Sun 2023-10-15 00:00:35 CEST; 1 day 13h
ago
Docs: man:systemd-sysv-generator(8)
Process: 10299 ExecStart=/etc/init.d/ntp start (code=exited,
status=0/SUCCESS)
Tasks: 2 (limit: 4483)
CPU: 4.446s
CGroup: /system.slice/ntp.service
├─10368 /usr/sbin/ntpd -u ntp:ntp -c /etc/ntp.conf
-l /var/log/ntp.log -p /var/run/ntp…
└─10370 "ntpd: asynchronous dns resolver"


eis64:/etc/init.d # service status ntp
● ntp.service
Loaded: loaded (/etc/init.d/ntp; generated)
Active: active (running) since Sun 2023-10-15 00:00:35 CEST; 1 day 13h
ago
Docs: man:systemd-sysv-generator(8)
Process: 10299 ExecStart=/etc/init.d/ntp start (code=exited,
status=0/SUCCESS)
Tasks: 2 (limit: 4483)
CPU: 4.446s
CGroup: /system.slice/ntp.service
├─10368 /usr/sbin/ntpd -u ntp:ntp -c /etc/ntp.conf
-l /var/log/ntp.log -p /var/run/ntp…
└─10370 "ntpd: asynchronous dns resolver"


Und nun mal restart statt staus unde ntp ist tot:

eis64:/etc/init.d # service status ntp
● ntp.service
Loaded: loaded (/etc/init.d/ntp; generated)
Active: active (exited) since Sun 2023-10-15 00:00:35 CEST; 1 day 13h
ago
Docs: man:systemd-sysv-generator(8)
Process: 10299 ExecStart=/etc/init.d/ntp start (code=exited,
status=0/SUCCESS)
CPU: 4.448s


Folge: Bei Initskripten geht der erste Parameter durch, andere entfallen auf
dem Weg. Jürgen musste in mail auch schon Aufrufe der Art

mail restart exim

entfernen, weil der Parameter exim keine Funktion mehr hat.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Marcus,

Am 15.10.23 um 20:31 schrieb Marcus Röckrath:

> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>> ich hatte Ende März auf systemd umgestellt und direkt ein Speicherleck auf
>> dem Eis. Dazu gibt es hier einen Thread "Speicherleck finden". Ich konnte
>> die Ursache nicht wirklich finden.
>
> Wenn du mal unter https://groups.google.com/g/spline.eisfair suchst, wirst
> du ähnliche Speicherprobleme (inklusive oom-Killer) aus der Zeit vor
> systemd finden; IMHO hat das auch nichts mit Systemd zu tun.

Hmm, wenn das jetzt mehrere Admins in einen Zusammenhang bringen....

> Kann du im Archiv bei Google mal nach oom-Kiler oder so suchen und schauen,
> ob das dort auf einigen wenigen Maschinen aufgetretene Probleme mit deinem
> vergleichbar ist?

Die Threads sind dort mindestens 3 Jahre alt. Danach hatte offensichtlich niemand mehr ein Problem damit. Soweit ich das jetzt durchforstet habe, konnte man keine konkrete Ursache ermitteln und suchte nach Analyse-Möglichkeiten.

> Wenn der oom-Killer laufende Programme killt, muss das nicht der Verursacher
> sein, sondern der Versuch des Kernels irgendwie wieder an Ram zu kommen.

Dass es hier keine Rückschlüsse auf Antispam zu ziehen sind, hatte ich bereits geschrieben. Allerdings ist hier die Häufigkeit, dass spamd gekillt wird, auffällig. Andere Prozesse waren in jüngster Zeit nicht mehr betroffen.

Ihm Rahmen eines Backup wird der Mailserver jeden 3. Tag neu gestartet. Mit dem Speicherupdate auf 8GB komme ich damit über die Runden. Ideal ist das aber nicht - und war vor dem systemd-Update definitiv anders.

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Kann du im Archiv bei Google mal nach oom-Kiler oder so suchen und
>> schauen, ob das dort auf einigen wenigen Maschinen aufgetretene Probleme
>> mit deinem vergleichbar ist?
>
> Die Threads sind dort mindestens 3 Jahre alt. Danach hatte offensichtlich
> niemand mehr ein Problem damit. Soweit ich das jetzt durchforstet habe,
> konnte man keine konkrete Ursache ermitteln und suchte nach
> Analyse-Möglichkeiten.

Mir ging es darum, ob du eventuell eine der damaligen Beobachtungen exakt
bestätigen kannst.

Mit vereinzelt auftretenden Problemen ist die Ursachenforschung meist sehr
schwierig und auch die Suche nach oom-Killer im Internet gibt nur ein sehr
difuses Bild ab.

>> Wenn der oom-Killer laufende Programme killt, muss das nicht der
>> Verursacher sein, sondern der Versuch des Kernels irgendwie wieder an Ram
>> zu kommen.
>
> Dass es hier keine Rückschlüsse auf Antispam zu ziehen sind, hatte ich
> bereits geschrieben. Allerdings ist hier die Häufigkeit, dass spamd
> gekillt wird, auffällig. Andere Prozesse waren in jüngster Zeit nicht mehr
> betroffen.

Oder es ist halt der Prozess, der nach Abwägung des Kernels eventuell
verantwortlich sein könnte:

[Zitat]
The function select_bad_process() is responsible for choosing a process to
kill. It decides by stepping through each running task and calculating how
suitable it is for killing with the function badness(). The badness is
calculated as follows, note that the square roots are integer
approximations calculated with int_sqrt();

badness_for_task = total_vm_for_task / (sqrt(cpu_time_in_seconds) *
sqrt(sqrt(cpu_time_in_minutes)))

This has been chosen to select a process that is using a large amount of
memory but is not that long lived. Processes which have been running a long
time are unlikely to be the cause of memory shortage so this calculation is
likely to select a process that uses a lot of memory but has not been
running long. If the process is a root process or has CAP_SYS_ADMIN
capabilities, the points are divided by four as it is assumed that root
privilege processes are well behaved. Similarly, if it has CAP_SYS_RAWIO
capabilities (access to raw devices) privileges, the points are further
divided by 4 as it is undesirable to kill a process that has direct access
to hardware.
[/Zitat]

Mit meinen Englischkenntnissen lese ich daraus, dass ein Prozess mit viel
Speicherverbrauch aber kurzer Laufzeit ein hohe Priorität als Verursachen
bekommt und dann ein Kill-Kandidat wird.

Nach meiner Erinnerung der damaligen Probleme, wurden nach und nach teils
auch immer neue Programme gekillt, was zumindest zeigt, dass die Heuristik
da wohl den "Bösewicht" nicht erkannt haben kann.

Wäre dir der spamd-Dienst so wichtig oder könntest du auf ihn mal eine Weile
verzichten?

Gab es in den damaligen Threads nicht auch einen Codeschnipsel, um den
Speicherverbrauch über Zeit zu dokumentieren?

> Ihm Rahmen eines Backup wird der Mailserver jeden 3. Tag neu gestartet.
> Mit dem Speicherupdate auf 8GB komme ich damit über die Runden. Ideal ist
> das aber nicht - und war vor dem systemd-Update definitiv anders.

Zumindest scheint es aber kein systemisches Problem zu sein, da systemd
inzwischen auf den meisten eisfair-Installationen aktiv sein dürfte und
auch spamd mehrfach eingesetzt werden dürfte, wenn ich mir für antispam die
Downloadstatistik anschaue (wenn sie auch durch Jäger und Sammler
verfälscht sein kann).

Vielleicht können sich auch mal andere eisfair-Nutzer kurz melden, wenn sie
antispam einsetzen.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Marcus,

Am 17.10.23 um 10:41 schrieb Marcus Röckrath:

> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>>> Kann du im Archiv bei Google mal nach oom-Kiler oder so suchen und
>>> schauen, ob das dort auf einigen wenigen Maschinen aufgetretene Probleme
>>> mit deinem vergleichbar ist?
>>
>> Die Threads sind dort mindestens 3 Jahre alt. Danach hatte offensichtlich
>> niemand mehr ein Problem damit. Soweit ich das jetzt durchforstet habe,
>> konnte man keine konkrete Ursache ermitteln und suchte nach
>> Analyse-Möglichkeiten.
>
> Mir ging es darum, ob du eventuell eine der damaligen Beobachtungen exakt
> bestätigen kannst.

Nunja, gab es denn in der Vergangenheit einen Fall der konkret auf eine Ursache zurückzuführen war? Soweit ich mich eingelesen habe, läuft der Speicher aus unerklärlicher Ursache voll bis der oom-killer zuschlägt. Lösung ist jeweils ein RAM-Update. Und diesen Sachverhalt kann ich bestätigen.

Hier ist es immer und ausschließlich spamd der gekillt wird.

> Wäre dir der spamd-Dienst so wichtig oder könntest du auf ihn mal eine Weile
> verzichten?

Und auch den Speicher wieder zu reduzieren? Auf einem Server könnte ich das machen.

> Gab es in den damaligen Threads nicht auch einen Codeschnipsel, um den
> Speicherverbrauch über Zeit zu dokumentieren?

Das hatte ich im Frühjahr auch hier gemacht. Ich sah allerdings nur, dass der Speicher zuläuft, aber nicht, welches Tool dafür die Ursache war. Die Erkenntnis daraus war nicht zielführend.

Grüße

Rolf

[Heinz-Peter Faasen]

Hallo Rolf,

> Ich sah allerdings nur, dass der Speicher zuläuft, aber nicht, welches
> Tool dafür die Ursache war. Die Erkenntnis daraus war nicht zielführend.

erfolgt der Anstieg der Speichernutzung sehr plötzlich oder eher langsam
und kontinuierlich?

Im zweiten Fall müsste Dir doch die Beobachtung mittels top
weiterhelfen, denn dort wird ja auch die Mem-Nutzung eines Prozesses
angezeigt.
Bei htop kannst Du sogar die Sortierung so einstellen, dass in der
ersten Zeile immer der Prozess mit der höchsten Speichernutzung
erscheint. Und dann evtl. die in eine Datei schreiben lassen.

Gruß
Heinz-Peter

[Marcus Röckrath]

Hallo Heinz-Peter,

Heinz-Peter Faasen wrote:

> Bei htop kannst Du sogar die Sortierung so einstellen, dass in der
> ersten Zeile immer der Prozess mit der höchsten Speichernutzung
> erscheint. Und dann evtl. die in eine Datei schreiben lassen.

Geht auch mit top.

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

> Nunja, gab es denn in der Vergangenheit einen Fall der konkret auf eine
> Ursache zurückzuführen war? Soweit ich mich eingelesen habe, läuft der
> Speicher aus unerklärlicher Ursache voll bis der oom-killer zuschlägt.
> Lösung ist jeweils ein RAM-Update. Und diesen Sachverhalt kann ich
> bestätigen.

Auch mehr Speicher wird, wenn man die Ursache nicht ermitteln kann,
irgendwann volllaufen und dann wieder zum oom-Killer führen - allerdings
wird es das Problem hinauszögern.

> Hier ist es immer und ausschließlich spamd der gekillt wird.
>
>> Wäre dir der spamd-Dienst so wichtig oder könntest du auf ihn mal eine
>> Weile verzichten?
> Und auch den Speicher wieder zu reduzieren? Auf einem Server könnte ich
> das machen.

Vielleicht auch das, um "schneller" Testen zu können.

>> Gab es in den damaligen Threads nicht auch einen Codeschnipsel, um den
>> Speicherverbrauch über Zeit zu dokumentieren?
>
> Das hatte ich im Frühjahr auch hier gemacht. Ich sah allerdings nur, dass
> der Speicher zuläuft, aber nicht, welches Tool dafür die Ursache war. Die
> Erkenntnis daraus war nicht zielführend.

Du hast nur die gesamte Speicherauslastung laut /proc/meminfo ausgelesen?

Ich meine, wir hätten damals top nach Memoryauslastung der Prozesse sortiert
protokolliert. Man kann nämlich top auch auf der Kommandozeile zu einer
einmaligen statt kontinuierlichen Ausgabe bewegen, z. B.:

while true; do
top -b -n 1 -o +VIRT | head -15 >> einelogdatei
sleep 5
done

--
Gruß Marcus
[eisfair-Team]

[Heinz-Peter Faasen]

Hi Marcus,

>> Bei htop kannst Du sogar die Sortierung so einstellen, dass in der
>> ersten Zeile immer der Prozess mit der höchsten Speichernutzung
>> erscheint. Und dann evtl. die in eine Datei schreiben lassen.
>
> Geht auch mit top.

ja, das waberte mir auch durch den Hnterkopf, war aber nicht sicher.

Und in solchen Fällen halte ich es gern mit Dieter Nuhr: "Wenn man keine
Ahnung hat: Einfach mal die ..... halten."

Aber natürlich trotzdem vielen Dank für den Hinweis!

Gruß
Heinz-Peter

[Marcus Röckrath]

Hallo Heinz-Peter,

Heinz-Peter Faasen wrote:

>>> Bei htop kannst Du sogar die Sortierung so einstellen, dass in der
>>> ersten Zeile immer der Prozess mit der höchsten Speichernutzung
>>> erscheint. Und dann evtl. die in eine Datei schreiben lassen.
>>
>> Geht auch mit top.
>
> ja, das waberte mir auch durch den Hnterkopf, war aber nicht sicher.

htop hat IMHO auch keinen Batchmodus, um mal in Abständen Werte in ein
Logfile zu schreiben.

> Und in solchen Fällen halte ich es gern mit Dieter Nuhr: "Wenn man keine
> Ahnung hat: Einfach mal die ..... halten."

Fällt Lehrern wie mir immer schwer. ;-)))))))))))))

> Aber natürlich trotzdem vielen Dank für den Hinweis!

Bitte.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Heinz-Peter,

Am 18.10.23 um 10:42 schrieb Heinz-Peter Faasen:

> Hallo Rolf,
>
>> Ich sah allerdings nur, dass der Speicher zuläuft, aber nicht, welches Tool dafür die Ursache war. Die Erkenntnis daraus war nicht zielführend.
>
> erfolgt der Anstieg der Speichernutzung sehr plötzlich oder eher langsam und kontinuierlich?

kontinuierlich

> Im zweiten Fall müsste Dir doch die Beobachtung mittels top weiterhelfen, denn dort wird ja auch die Mem-Nutzung eines Prozesses angezeigt.
> Bei htop kannst Du sogar die Sortierung so einstellen, dass in der ersten Zeile immer der Prozess mit der höchsten Speichernutzung erscheint. Und dann evtl. die in eine Datei schreiben lassen.

Das folgt im nächsten Schritt.

Grüße

Rolf

[Rolf Bensch]

Hallo Marcus,

Am 18.10.23 um 11:22 schrieb Marcus Röckrath:

> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>> Nunja, gab es denn in der Vergangenheit einen Fall der konkret auf eine
>> Ursache zurückzuführen war? Soweit ich mich eingelesen habe, läuft der
>> Speicher aus unerklärlicher Ursache voll bis der oom-killer zuschlägt.
>> Lösung ist jeweils ein RAM-Update. Und diesen Sachverhalt kann ich
>> bestätigen.
>
> Auch mehr Speicher wird, wenn man die Ursache nicht ermitteln kann,
> irgendwann volllaufen und dann wieder zum oom-Killer führen - allerdings
> wird es das Problem hinauszögern.

das wird hier durch den Server-Neustart alle 3 Tage aufgefangen.

>> Hier ist es immer und ausschließlich spamd der gekillt wird.
>>
>>> Wäre dir der spamd-Dienst so wichtig oder könntest du auf ihn mal eine
>>> Weile verzichten?
>> Und auch den Speicher wieder zu reduzieren? Auf einem Server könnte ich
>> das machen.

Habe den Speicher auf 2GB reduziert und nach ca. 12 Stunden wurde wieder spamd abgeschossen. Habe Antispam und Antispam-Razor jetzt testweise deaktiviert.

In diesem Zusammenhang:
nach setzen von "START_ANTISPAM = no" und Neustart des Server war der Service weiterhin aktiv.

>
> Vielleicht auch das, um "schneller" Testen zu können.
>
>>> Gab es in den damaligen Threads nicht auch einen Codeschnipsel, um den
>>> Speicherverbrauch über Zeit zu dokumentieren?
>>
>> Das hatte ich im Frühjahr auch hier gemacht. Ich sah allerdings nur, dass
>> der Speicher zuläuft, aber nicht, welches Tool dafür die Ursache war. Die
>> Erkenntnis daraus war nicht zielführend.
>
> Du hast nur die gesamte Speicherauslastung laut /proc/meminfo ausgelesen?

ich hatte überwiegend "free" verwendet. Später dann über ps die pid des Dienstes mit dem größten Speicherverbrauch ermittelt um daraus weitere Analysen zu fahren. Details dazu finde ich aktuell nicht mehr.

>
> Ich meine, wir hätten damals top nach Memoryauslastung der Prozesse sortiert
> protokolliert. Man kann nämlich top auch auf der Kommandozeile zu einer
> einmaligen statt kontinuierlichen Ausgabe bewegen, z. B.:
>
> while true; do
> top -b -n 1 -o +VIRT | head -15 >> einelogdatei
> sleep 5
> done
>

Ich warte jetzt mal ab wie der Server mit reduzierten Speicher, abgeschalteten Antispam und ohne Restart läuft. Treten wieder oom-killer auf, ist antispam nicht die Ursache und wir können mit dem Codeschnipsel weiter suchen.

Grüße

Rolf

[Heinz-Peter Faasen]

Hallo Rolf,

> Ich warte jetzt mal ab wie der Server mit reduzierten Speicher,
> abgeschalteten Antispam und ohne Restart läuft. Treten wieder oom-killer
> auf, ist antispam nicht die Ursache und wir können mit dem Codeschnipsel
> weiter suchen.

irgendwie verstehe ich Deine Strategie nicht. Warum nicht gleich
schauen, wer da den Müll verursacht und entsprechend handeln?

Gruß
Heinz-Peter

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

> In diesem Zusammenhang:
> nach setzen von "START_ANTISPAM = no" und Neustart des Server war der
> Service weiterhin aktiv.

Danke für den Hinweis, da schauen wir dann mal ins Paket.

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

> In diesem Zusammenhang:
> nach setzen von "START_ANTISPAM = no" und Neustart des Server war der
> Service weiterhin aktiv.

Wie hast du das genau festgestellt?

Durch service status antispam?

Oder?

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Marcus,

Am 20.10.23 um 17:24 schrieb Marcus Röckrath:

> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>> In diesem Zusammenhang:
>> nach setzen von "START_ANTISPAM = no" und Neustart des Server war der
>> Service weiterhin aktiv.
>
> Wie hast du das genau festgestellt?
>
> Durch service status antispam?

prinzipiell ja, aufgerufen durch den Menüpunkt "Show Status".

Vielleicht noch ergänzend dazu: im Mailpaket war zu diesem Zeitpunkt "EXISCAN_SPAMD_ENABLED = yes" noch gesetzt. Das habe ich erst späte deaktiviert.

Grüße

Rolf

[Rolf Bensch]

Hallo Heinz-Peter,

Am 20.10.23 um 09:56 schrieb Heinz-Peter Faasen:

> Hallo Rolf,
>
>> Ich warte jetzt mal ab wie der Server mit reduzierten Speicher, abgeschalteten Antispam und ohne Restart läuft. Treten wieder oom-killer auf, ist antispam nicht die Ursache und wir können mit dem Codeschnipsel weiter suchen.
>
> irgendwie verstehe ich Deine Strategie nicht. Warum nicht gleich schauen, wer da den Müll verursacht und entsprechend handeln?

Einfach um Antispam als Verursacher auszuschließen.

Ich habe noch etwas gestöbert. In /var/log/messages gibt's, wie immer, eine Menge Output zum kill-Prozess. Der beginnt mit:

Oct 18 18:54:02 mail kernel: spamd child invoked oom-killer: gfp_mask=0x1100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0

Ich interpretiere das so, dass spamd den oom-killer angestoßen hat. Bisher ging ich davon aus, dass oom-killer aufgrund von Speichermangel per select_bad_process() dem spamd eine gewisse Wahrscheinlichkeit unterjubelt und deshalb den Prozess killt. Das scheint hier anders gelagert zu sein.

Ferner aus dem Logfile:
Oct 18 18:54:03 mail kernel: [ 775] 0 775 65583 43051 638976 0 0 spamd
Oct 18 18:54:03 mail kernel: [ 776] 2022 776 190129 164770 1638400 0 0 spamd child
Oct 18 18:54:03 mail kernel: [ 777] 2022 777 67111 44535 643072 0 0 spamd child
Oct 18 18:54:03 mail kernel: [ 778] 2022 778 67335 44755 643072 0 0 spamd child
Oct 18 18:54:03 mail kernel: [ 779] 2022 779 253633 217283 2060288 0 0 spamd child
Oct 18 18:54:03 mail kernel: [ 781] 2022 781 66631 44092 638976 0 0 spamd child

Zum Laufzeit des oom-killer laufen 5 child-Prozesse von spamd. Im exim-mainlog finde ich zu dieser Uhrzeit:

2023-10-18 18:54:02 1qt9nt-0000Jh-2P spam acl condition: cannot parse spamd [127.0.0.1]:783 output

der Dienst scheint also schon tot zu sein. In der vorausgegangenen Stunde wurden 5 eMails verarbeitet, die letzte etwa 60 Sekunden zuvor. Eine Erklärung weshalb hier 5 Prozesse laufen müssen habe ich nicht. Der Prozess 779 wurde letztendlich gekillt.

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

> Ich habe noch etwas gestöbert. In /var/log/messages gibt's, wie immer,
> eine Menge Output zum kill-Prozess. Der beginnt mit:
>
> Oct 18 18:54:02 mail kernel: spamd child invoked oom-killer:
> gfp_mask=0x1100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0,
> oom_score_adj=0

IMHO stößt ihn immer irgendein Prozess an, wenn er Speicher anfordert, der
Kernel ihn dann aber nicht mehr befriedigen kann.

> Ferner aus dem Logfile:
> Oct 18 18:54:03 mail kernel: [ 775] 0 775 65583 43051
> 638976 0 0 spamd
> Oct 18 18:54:03 mail kernel: [ 776] 2022 776 190129 164770
> 1638400 0 0 spamd child
> Oct 18 18:54:03 mail kernel: [ 777] 2022 777 67111 44535
> 643072 0 0 spamd child
> Oct 18 18:54:03 mail kernel: [ 778] 2022 778 67335 44755
> 643072 0 0 spamd child
> Oct 18 18:54:03 mail kernel: [ 779] 2022 779 253633 217283
> 2060288 0 0 spamd child
> Oct 18 18:54:03 mail kernel: [ 781] 2022 781 66631 44092
> 638976 0 0 spamd child
>
> Zum Laufzeit des oom-killer laufen 5 child-Prozesse von spamd. Im
> exim-mainlog finde ich zu dieser Uhrzeit:
>
> 2023-10-18 18:54:02 1qt9nt-0000Jh-2P spam acl condition: cannot parse
> spamd [127.0.0.1]:783 output
>
> der Dienst scheint also schon tot zu sein. In der vorausgegangenen Stunde
> wurden 5 eMails verarbeitet, die letzte etwa 60 Sekunden zuvor. Eine
> Erklärung weshalb hier 5 Prozesse laufen müssen habe ich nicht. Der
> Prozess 779 wurde letztendlich gekillt.

Es gibt auch andere Dienste, die mehrere Childs starten:

7485 ? Ss 0:01 /usr/sbin/apache2 -k start
7492 ? Sl 0:00 /usr/sbin/apache2 -k start
7493 ? Sl 0:00 /usr/sbin/apache2 -k start
7494 ? Sl 0:00 /usr/sbin/apache2 -k start

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Durch service status antispam?
>
> prinzipiell ja, aufgerufen durch den Menüpunkt "Show Status".

Da muss man bei Init-Skripts etwas aufpassen.

Stand active (exited) oder active (running).

Nach Studium des antispam-Paketes vermute ich ersteres, was nicht bedeutet,
dass es aktiv ist.

Das antispam-Initsckript wird nämlich auch dann gestartet, wenn der Dienst
deaktiviert ist, prüft aber intern den Status der Startvariablen, um dann
nur bei yes wirklich den Dienst zu starten.

--
Gruß Marcus
[eisfair-Team]

[Heinz-Peter Faasen]

Hallo Rolf,

>> irgendwie verstehe ich Deine Strategie nicht. Warum nicht gleich
>> schauen, wer da den Müll verursacht und entsprechend handeln?
>
> Einfach um Antispam als Verursacher auszuschließen.

ok, dann warten wir die Ergebnisse mal ab.

> Der Prozess 779 wurde letztendlich gekillt.

Wahrscheinlich, weil er die "besten" Ergebnisse versprach.

Gruß
Heinz-Peter

[Marcus Röckrath]

Hallo Heinz-Peter,

Heinz-Peter Faasen wrote:

>> Der Prozess 779 wurde letztendlich gekillt.
>
> Wahrscheinlich, weil er die "besten" Ergebnisse versprach.

Sehe ich auch so.

Der Kernel versucht die Situation in den Griff zu bekommen, was zunächst
bedeutet, dass er die Speicheranforderung eines Programms erfüllen möchte.

Das ein Programm Speicher anfordert, ist ja erstmal eine normale Sache, dass
der Speicherbedarf einesProgramms während des lauufenden Betriebs variabel
ist auch.

Das ein Programm eventuell wegen eines Bugs nicht mehr benötigte
Speicherbereiche nicht mehr freigibt, kann der Kernel nicht entscheiden;
das ein Programm immer mehr Speicher belegt könnte ein Indiz aber kein
Beweis sein.

Jetzt kommt die Heuristik des oom-Killers ins Spiel, der etwas finden muss,
was soviel Speicher frei macht, wie gerade angefordert wird.

Wenn er wüsste, wer hier ein bugbedingtes Problem hätte, könnte er gezielt
diesen Prozess killen.

Letzlich bleibt, große Speicherfresser mal zu deaktivieren und erneut zu
beobachten.

--
Gruß Marcus
[eisfair-Team]

[Nils Lange]

Hallo Marcus und Rolf,

On 17.10.2023 10:41, Marcus Röckrath wrote:
>
> Vielleicht können sich auch mal andere eisfair-Nutzer kurz melden, wenn sie
> antispam einsetzen.
>

ich betreibe einen Mailserver mit antispam und habe derartige Probleme
nicht festgestellt. Maschine läuft seit 98 Tagen und hat nur 4gb RAM,
von dem noch 2gb frei sind.

Gruß, Nils

[Rolf Bensch]

Hallo zusammen!

Am 20.10.23 um 08:23 schrieb Rolf Bensch:

>
> Habe den Speicher auf 2GB reduziert und nach ca. 12 Stunden wurde wieder spamd abgeschossen. Habe Antispam und Antispam-Razor jetzt testweise deaktiviert.

das war vor mehr als 2 Tagen. Seitdem kein Neustart des Server und auch kein oom-killer im Logfile. Die Speicherauslastung liegt konstant bei ca 50%, Swap-Speicher wird nicht angetastet. Das sind traumhafte Zustände!

Wie weiter? Ist das jetzt ein konkreter Fingerzeig auf spamd als Verursacher? Sollte ich spamd nochmals aktivieren um das zu verifizieren? Welche Analysen schlagt ihr vor?

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Habe den Speicher auf 2GB reduziert und nach ca. 12 Stunden wurde wieder
>> spamd abgeschossen. Habe Antispam und Antispam-Razor jetzt testweise
>> deaktiviert.
>
> das war vor mehr als 2 Tagen. Seitdem kein Neustart des Server und auch
> kein oom-killer im Logfile. Die Speicherauslastung liegt konstant bei ca
> 50%, Swap-Speicher wird nicht angetastet. Das sind traumhafte Zustände!
>
> Wie weiter? Ist das jetzt ein konkreter Fingerzeig auf spamd als
> Verursacher?

Ein Indiz ist es IMHO schon, wenn ohne spamd der Speicherverbrauch
unauffällig ist.

Wenn es allerdings ein generelles spamd-Problem wäre, sollte das hier
deutlich häufiger bemerkt werden.

War das eigentlich ein virtuelles System oder echtes Blech?

Waren das in den alten Threads nicht eher virtuelle Systeme, die über
oom-Killer berichteten?

> Sollte ich spamd nochmals aktivieren um das zu verifizieren?
> Welche Analysen schlagt ihr vor?

Als Gegentest vielleicht nicht schlecht.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Marcus,

Am 22.10.23 um 10:45 schrieb Marcus Röckrath:

> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>>> Habe den Speicher auf 2GB reduziert und nach ca. 12 Stunden wurde wieder
>>> spamd abgeschossen. Habe Antispam und Antispam-Razor jetzt testweise
>>> deaktiviert.
>>
>> das war vor mehr als 2 Tagen. Seitdem kein Neustart des Server und auch
>> kein oom-killer im Logfile. Die Speicherauslastung liegt konstant bei ca
>> 50%, Swap-Speicher wird nicht angetastet. Das sind traumhafte Zustände!
>>
>> Wie weiter? Ist das jetzt ein konkreter Fingerzeig auf spamd als
>> Verursacher?
>
> Ein Indiz ist es IMHO schon, wenn ohne spamd der Speicherverbrauch
> unauffällig ist.
>
> Wenn es allerdings ein generelles spamd-Problem wäre, sollte das hier
> deutlich häufiger bemerkt werden.

Nunja - man erhält keine Info darüber. Man muss explizit nach der Fehlermeldung suchen oder der Server steht und muss neu gestartet werden.

> War das eigentlich ein virtuelles System oder echtes Blech?

virtualisiert mit kvm/qemu. Der Host ist unauffällig und shared Memory nutze ich nicht. Es gibt hier noch ein nahezu identisches System. Gerade erkannt: auf dem anderen Mailserver schlägt der oom-killer täglich zu wenn '/var/install/config.d/antispam.sh --learnhamspam' läuft. Hier wird allerdings immer sa-learn gekillt. Diesem Server gönne ich jetzt mal etwas mehr RAM.

> Waren das in den alten Threads nicht eher virtuelle Systeme, die über
> oom-Killer berichteten?

Ja.

>> Sollte ich spamd nochmals aktivieren um das zu verifizieren?
>> Welche Analysen schlagt ihr vor?
>
> Als Gegentest vielleicht nicht schlecht.

Soeben erledigt.

Grüße

Rolf

[Rolf Bensch]

....

>>> Sollte ich spamd nochmals aktivieren um das zu verifizieren?
>>> Welche Analysen schlagt ihr vor?
>>
>> Als Gegentest vielleicht nicht schlecht.
>
> Soeben erledigt.

Vielleicht noch ein paar Eckdaten:

Nach Neustart des Servers:
top - 14:06:23 up 1 min, 1 user, load average: 0.74, 0.30, 0.11
Tasks: 131 total, 1 running, 130 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.2 sy, 0.0 ni, 99.5 id, 0.2 wa, 0.0 hi, 0.0 si, 0.2 st
MiB Mem : 1810.699 total, 1316.438 free, 537.891 used, 189.746 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 1272.809 avail Mem

Es werden auch direkt wieder 5 Childs erzeugt:
mail # ps -A | grep spamd
795 ? 00:00:01 spamd
796 ? 00:00:00 spamd child
797 ? 00:00:00 spamd child
798 ? 00:00:00 spamd child
799 ? 00:00:00 spamd child
801 ? 00:00:00 spamd child


Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Wenn es allerdings ein generelles spamd-Problem wäre, sollte das hier
>> deutlich häufiger bemerkt werden.
>
> Nunja - man erhält keine Info darüber. Man muss explizit nach der
> Fehlermeldung suchen oder der Server steht und muss neu gestartet werden.

Zumindest ein Stehenbleiben sollte auffallen, und das ist letztlich doch
immer die Konsequenz, weil ewig kann es der oom-Killer nicht halten, außer
er erwischt den Verursacher.

Vorher könnte auffallen, dass einzelne Dienste fehlen oder das System immer
träger wird.

>> War das eigentlich ein virtuelles System oder echtes Blech?
>
> virtualisiert mit kvm/qemu. Der Host ist unauffällig und shared Memory
> nutze ich nicht. Es gibt hier noch ein nahezu identisches System. Gerade
> erkannt: auf dem anderen Mailserver schlägt der oom-killer täglich zu wenn
> '/var/install/config.d/antispam.sh --learnhamspam' läuft. Hier wird
> allerdings immer sa-learn gekillt. Diesem Server gönne ich jetzt mal etwas
> mehr RAM.
>
>> Waren das in den alten Threads nicht eher virtuelle Systeme, die über
>> oom-Killer berichteten?
>
> Ja.

Das es (vermehrt) virtuelle Maschinen trifft, ist schon erstaunlich.

Wie steht bei dir:

ANTISPAM_MAX_CHILDREN
Dieser Parameter legt fest, wie viele Kindprozesse maximal
gleichzeitig auf dem Server aktiviert werden sollen. Auf sehr
langsamer Hardware ist es manchmal sinnvoll diesen Parameter
anzupassen. Standardmaessig werden die systemspezifischen
Einstellungen verwendet.

Wenn es wirklich der spamassasin-Daemon ist, könnte man vielleicht auch mal
in deren Forum nach Mitleidenden fragen.

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

> Es werden auch direkt wieder 5 Childs erzeugt:
> mail # ps -A | grep spamd
> 795 ? 00:00:01 spamd
> 796 ? 00:00:00 spamd child
> 797 ? 00:00:00 spamd child
> 798 ? 00:00:00 spamd child
> 799 ? 00:00:00 spamd child
> 801 ? 00:00:00 spamd child

IMHO ist das normal, machen andere Dienste auch, schau mal in die
Prozessliste, wer da wie viele Unterprozesse startet.

IMHO kannst du das im Antispam-Paket aber selbst festlegen:

ANTISPAM_MAX_CHILDREN
Dieser Parameter legt fest, wie viele Kindprozesse maximal
gleichzeitig auf dem Server aktiviert werden sollen. Auf sehr
langsamer Hardware ist es manchmal sinnvoll diesen Parameter
anzupassen. Standardmaessig werden die systemspezifischen
Einstellungen verwendet.

Gueltige Werte: Zahl

Standardeinstellung: ANTISPAM_MAX_CHILDREN='0'

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Moin Marcus,

Am 22.10.23 um 14:14 schrieb Marcus Röckrath:

> Wie steht bei dir:
>
> ANTISPAM_MAX_CHILDREN
> Dieser Parameter legt fest, wie viele Kindprozesse maximal
> gleichzeitig auf dem Server aktiviert werden sollen. Auf sehr
> langsamer Hardware ist es manchmal sinnvoll diesen Parameter
> anzupassen. Standardmaessig werden die systemspezifischen
> Einstellungen verwendet.

mail # grep -i children /etc/config.d/antispam
ANTISPAM_MAX_CHILDREN='0'

stellt sich die Frage, was diese Child-Prozesse bewirken. Parallel-Verarbeitung? Ich sehe nicht, dass exim das unterstützt - oder doch?

> Wenn es wirklich der spamassasin-Daemon ist, könnte man vielleicht auch mal
> in deren Forum nach Mitleidenden fragen.

Da gibt es einiges zu lesen. Allerdings inhaltlich wenig nutzbares.

Grüße

Rolf

[Rolf Bensch]

Hallo Nils,

Am 22.10.23 um 02:03 schrieb Nils Lange:

Danke für die Info. Ein paar Fragen dazu:

- Blech oder virtualisiert?
- läuft bei Dir Antispam_razor?
- läuft bei Dir im Antispam-Paket ein "force rules update" fehlerfrei durch?

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> ANTISPAM_MAX_CHILDREN
>> Dieser Parameter legt fest, wie viele Kindprozesse maximal
>> gleichzeitig auf dem Server aktiviert werden sollen. Auf sehr
>> langsamer Hardware ist es manchmal sinnvoll diesen Parameter
>> anzupassen. Standardmaessig werden die systemspezifischen
>> Einstellungen verwendet.
>
> mail # grep -i children /etc/config.d/antispam
> ANTISPAM_MAX_CHILDREN='0'

Was bedeutet, dass die Standard-Einstellungen (im Kernel?) genutzt werden.

> stellt sich die Frage, was diese Child-Prozesse bewirken.
> Parallel-Verarbeitung? Ich sehe nicht, dass exim das unterstützt - oder
> doch?

Ich denke ja, das es in diese Richtung geht.

Ob exim das unterstützt ist doch IMHO zweitrangig, da der spamassin ein
eigenständiger Dienst ist, der ja erstmal nichts davon weiß, wer seine
Dienste in Anspruch nimmt.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Moin zusammen,

Am 21.10.23 um 12:01 schrieb Marcus Röckrath:

> Letzlich bleibt, große Speicherfresser mal zu deaktivieren und erneut zu beobachten.

an diesem Punkt sind wir jetzt wohl. Kurze Zusammenfassung Stand heute Morgen:

- Der Server wurde vor ca. 18 Stunden neu gestartet
- Antispam ist aktiv, Antispam_razor (noch) nicht. Weil es Probleme beim Update gab, habe ich 2 URLs aus ANTISPAM_RULE_CHANNEL* entfernt. Aktuell wird nur über http://spamassassin.apache.org aktualisiert.
- top wird jetzt in 5 Minuten-Intervallen protokolliert.

Ausgaben von top:
Start der Protokollierung
top - 16:55:00 up 2:49, 1 user, load average: 0.16, 0.20, 0.16
Tasks: 129 total, 1 running, 128 sleeping, 0 stopped, 0 zombie
%Cpu(s): 15.6 us, 43.8 sy, 0.0 ni, 28.1 id, 0.0 wa, 0.0 hi, 0.0 si, 12.5 st
MiB Mem : 1810.699 total, 1219.398 free, 571.008 used, 268.426 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 1239.691 avail Mem
um Mitternacht:
top - 00:00:00 up 9:54, 0 users, load average: 0.12, 0.14, 0.10
Tasks: 146 total, 2 running, 142 sleeping, 0 stopped, 2 zombie
%Cpu(s): 18.8 us, 50.0 sy, 0.0 ni, 21.9 id, 0.0 wa, 0.0 hi, 0.0 si, 9.4 st
MiB Mem : 1810.699 total, 1198.766 free, 541.605 used, 319.434 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 1269.094 avail Mem
aktuell:
top - 07:55:00 up 17:49, 1 user, load average: 0.10, 0.13, 0.11
Tasks: 134 total, 1 running, 133 sleeping, 0 stopped, 0 zombie
%Cpu(s): 21.9 us, 37.5 sy, 0.0 ni, 31.2 id, 3.1 wa, 0.0 hi, 0.0 si, 6.2 st
MiB Mem : 1810.699 total, 1043.762 free, 616.875 used, 408.523 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 1193.824 avail Mem

Der freie Speicher schmilzt also langsam zusammen. Lasse ab sofort die Top-5-Speicherverbrauch-Dienste mit protokollieren.

Einen sehr ähnlichen Server habe ich gestern von 2GB auf 4GB aufgerüstet. Dort läuft zusätzlich antispam_razor, der Speicher schmilzt auch hier zusammen. Mit 2GB hatte der oom-killer reproduzierbar nach 'antispam.shg --learnhamspam' ausgelöst. Nach dem Update auf 4GB blieb das aus. Um das Problem vielleicht etwas zu forcieren, läuft learnhamspam jetzt täglich auf dem hier besprochenen Server.

Wäre jetzt vielleicht auch noch geschickt Antispam nochmals zu deaktivieren um zu sehen, ob der Speicher weiter schmilzt. Das mache ich dann wenn der oom-killer zugeschlagen hat.

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

Diese Ausgaben halte ich nicht für aussagekräftig, da sie nichts über den
Speicherverbrauch der Anwendungen aussagt.

Das im wesentlichen ablesbar ist, das die Cache/Buffer-Nutzung zunimmt ist
normal, denn freien Speicher benutzt der Kernel immer recht exessiv dafür.

Wir brauchen zwingend die Top-Programmspeicherverbraucher und müssen hier
welche dingfest machen, die stetig mehr Speicher belegen.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Am 23.10.23 um 10:55 schrieb Marcus Röckrath:
...

> Diese Ausgaben halte ich nicht für aussagekräftig, da sie nichts über den
> Speicherverbrauch der Anwendungen aussagt.

top - 15:10:00 up 1 day, 1:04, 0 users, load average: 0.16, 0.16, 0.10
Tasks: 147 total, 4 running, 142 sleeping, 0 stopped, 1 zombie
%Cpu(s): 37.5 us, 46.9 sy, 0.0 ni, 12.5 id, 0.0 wa, 0.0 hi, 0.0 si, 3.1 st
MiB Mem : 1810.699 total, 862.910 free, 759.207 used, 447.512 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 1051.492 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11951 spam 20 0 267864 189708 7780 S 0.000 10.23 0:00.61 spamd chi+
11953 spam 20 0 224040 149160 9144 S 0.000 8.045 0:00.83 spamd chi+
11954 spam 20 0 221132 146420 9208 S 0.000 7.897 0:00.50 spamd chi+
11950 spam 20 0 217076 140756 7540 S 0.000 7.591 0:00.26 spamd chi+
11947 root 20 0 215304 142068 10552 S 0.000 7.662 0:01.15 spamd
11955 spam 20 0 215304 134640 3124 S 0.000 7.262 0:00.00 spamd chi+
11803 spam 20 0 152632 2968 2484 S 0.000 0.160 0:01.62 gpg-agent
17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:02.28 gpg-agent

ist das so besser? oder sollte ich noch mehr Zeilen mitloggen?

> Das im wesentlichen ablesbar ist, das die Cache/Buffer-Nutzung zunimmt ist
> normal, denn freien Speicher benutzt der Kernel immer recht exessiv dafür.

ich hatte mich immer am "free"-Wert für Mem und Swap und an "Tasks" orientiert. Ist das nicht aussagekräftig?

Von ursprünglich 1219.398 free Mem sind aktuell noch 862.910 übrig. Der Speicherverbrauch der spamd-Tasks steigt langsam an. Zum Vergleich die Daten von heute Morgen 08:50 Uhr:

top - 08:50:00 up 18:44, 1 user, load average: 0.06, 0.14, 0.15
Tasks: 143 total, 2 running, 141 sleeping, 0 stopped, 0 zombie
%Cpu(s): 22.6 us, 45.2 sy, 0.0 ni, 12.9 id, 0.0 wa, 0.0 hi, 0.0 si, 19.4 st
MiB Mem : 1810.699 total, 1086.402 free, 557.129 used, 425.734 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 1253.570 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11947 root 20 0 215304 142068 10552 S 0.000 7.662 0:00.92 spamd
11950 spam 20 0 215304 134768 3252 S 0.000 7.268 0:00.00 spamd chi+
11951 spam 20 0 215304 134640 3124 S 0.000 7.262 0:00.00 spamd chi+
11953 spam 20 0 215304 134768 3252 S 0.000 7.268 0:00.00 spamd chi+
11954 spam 20 0 215304 134768 3252 S 0.000 7.268 0:00.00 spamd chi+
11955 spam 20 0 215304 134640 3124 S 0.000 7.262 0:00.00 spamd chi+
11803 spam 20 0 152632 2968 2484 S 0.000 0.160 0:00.91 gpg-agent
17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:01.60 gpg-agent

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

Ja, ich denke schon, denn den %MEM sieht man, dass spam alleine rund 50% des
Speichers belegt.

Lass uns das mal beobachten; lässt du das in eine Datei Loggen?

Dann kann man die nach dem Crash mal in Ruhe asuwerten, wozu du die mir dann
auch gerne per PM zusenden darfst.

>> Das im wesentlichen ablesbar ist, das die Cache/Buffer-Nutzung zunimmt
>> ist normal, denn freien Speicher benutzt der Kernel immer recht exessiv
>> dafür.
>
> ich hatte mich immer am "free"-Wert für Mem und Swap und an "Tasks"
> orientiert. Ist das nicht aussagekräftig?

Wenn er viel Cached, ist Mem auch klein; siehe mein Haupteis:

MiB Mem : 2772.457 total, 112.145 free, 275.672 used, 2508.020 buff/cache

Der verbrät fast den ganzen Ram für Caching und Buffering, ohne auch nur in
den Verdacht des oom-Killers zu kommen.

> Von ursprünglich 1219.398 free Mem sind aktuell noch 862.910 übrig. Der
> Speicherverbrauch der spamd-Tasks steigt langsam an. Zum Vergleich die
> Daten von heute Morgen 08:50 Uhr:

Und hat dann viel weniger Platz fürs Caching, welches bei dir deutlich
weniger genutzt wird.

Falls sich der spamd wirklich als die Achillesverse rausstellt, würde ich
mir die Frage stellen - und es wäre schön, wenn hier alle, die spamd nutzen
mal schreiben, ob sie Probleme habe, ob es Hardware oder Virt-System ist -
warum es möglicherweise eher Virt-Systeme trifft.

--
Gruß Marcus
[eisfair-Team]

[Dirk Alberti]

Hallo Marcus,

Am 23.10.23 um 16:24 schrieb Marcus Röckrath:

> Falls sich der spamd wirklich als die Achillesverse rausstellt, würde ich
> mir die Frage stellen - und es wäre schön, wenn hier alle, die spamd nutzen
> mal schreiben, ob sie Probleme habe, ob es Hardware oder Virt-System ist -
> warum es möglicherweise eher Virt-Systeme trifft.
>

dann klinke ich mich mal hier mit der Meldung ein, dass bei mir auf dem
Hardware-Eis antispam keine Probleme macht. Er hat aber auch nur 6
private Postfächer zu bedienen.
Wie man sieht, läuft er seit dem letzten Reboot schon wieder einige Tage:

eisfair # usr/sbin/service status antispam
-bash: usr/sbin/service: No such file or directory
eisfair # /usr/sbin/service status antispam
● antispam.service
Loaded: loaded (/etc/init.d/antispam; generated)
Active: active (running) since Sat 2023-10-14 09:25:35 CEST; 1
week 2 days ago
Docs: man:systemd-sysv-generator(8)
Tasks: 2 (limit: 4915)
CPU: 18h 46min 27.651s
CGroup: /system.slice/antispam.service
├─12637 sleep 20
└─12830 /bin/sh /var/install/bin/antispam-control

Oct 14 09:25:18 eisfair systemd[1]: Starting antispam.service...
Oct 14 09:25:24 eisfair antispam[11685]: * Starting spamd daemon ...
Oct 14 09:25:25 eisfair antispam[11685]: [26B blob data]
Oct 14 09:25:35 eisfair antispam[11685]: * Starting antispam-control
process ...
Oct 14 09:25:35 eisfair antispam[11685]: [26B blob data]
Oct 14 09:25:35 eisfair systemd[1]: Started antispam.service.


Und mein Eisfair ist auch keine "Super-Highend-Maschine"

eisfair # free -h
total used free shared buff/cache
available
Mem: 7.8Gi 2.1Gi 613Mi 64Mi 5.9Gi
5.7Gi
Swap: 3.3Gi 53Mi 3.3Gi


Grüße, Dirk

[Sascha Pohl]

Hallo Marcus,

Am 23.10.2023 um 16:24 schrieb Marcus Röckrath:

> Falls sich der spamd wirklich als die Achillesverse rausstellt, würde ich
> mir die Frage stellen - und es wäre schön, wenn hier alle, die spamd nutzen
> mal schreiben, ob sie Probleme habe, ob es Hardware oder Virt-System ist -
> warum es möglicherweise eher Virt-Systeme trifft.

dann will ich mich an dieser Stelle auch einmal zu Wort melden,
schließlich habe ich die Diskussion ins Rollen gebracht.
Vorweg die Info, dass es sich bei mir wohl um ein ganz anderes Problem
handelt, da ich in meinen Logs zu keiner Zeit einen oom-Killer finden kann.
Mein eisfair-64 läuft als virtuelle Maschine.
Bis vor kurzem kam lief er immer mit 4GB RAM, zur Zeit habe ich
testweise auf 6GB erhöht und gleichzeitig clamav deaktiviert.
Einen Grund, warum sich spamd und auch mini-http irgendwann
verabschieden habe ich noch immer nicht eingrenzen können. Die Logfiles
geben dazu keinerlei Informationen.

Grüße
Sascha

[Rolf Bensch]

Hallo Marcus,

Am 23.10.23 um 16:24 schrieb Marcus Röckrath:

ja.

> Dann kann man die nach dem Crash mal in Ruhe asuwerten, wozu du die mir dann
> auch gerne per PM zusenden darfst.

gerne.

>>> Das im wesentlichen ablesbar ist, das die Cache/Buffer-Nutzung zunimmt
>>> ist normal, denn freien Speicher benutzt der Kernel immer recht exessiv
>>> dafür.
>>
>> ich hatte mich immer am "free"-Wert für Mem und Swap und an "Tasks"
>> orientiert. Ist das nicht aussagekräftig?
>
> Wenn er viel Cached, ist Mem auch klein; siehe mein Haupteis:
>
> MiB Mem : 2772.457 total, 112.145 free, 275.672 used, 2508.020 buff/cache
>
> Der verbrät fast den ganzen Ram für Caching und Buffering, ohne auch nur in
> den Verdacht des oom-Killers zu kommen.
>
>> Von ursprünglich 1219.398 free Mem sind aktuell noch 862.910 übrig. Der
>> Speicherverbrauch der spamd-Tasks steigt langsam an. Zum Vergleich die
>> Daten von heute Morgen 08:50 Uhr:
>
> Und hat dann viel weniger Platz fürs Caching, welches bei dir deutlich
> weniger genutzt wird.
>
> Falls sich der spamd wirklich als die Achillesverse rausstellt, würde ich
> mir die Frage stellen - und es wäre schön, wenn hier alle, die spamd nutzen
> mal schreiben, ob sie Probleme habe, ob es Hardware oder Virt-System ist -
> warum es möglicherweise eher Virt-Systeme trifft.

Stand heute Morgen: oom-killer hat noch nicht zugeschlagen. Antispam_razor ist weiterhin abgeschaltet. Mem-Infos finde ich unauffällig:

top - 09:30:00 up 1 day, 19:21, 0 users, load average: 0.19, 0.19, 0.13
Tasks: 149 total, 2 running, 147 sleeping, 0 stopped, 0 zombie
%Cpu(s): 25.8 us, 54.8 sy, 0.0 ni, 16.1 id, 0.0 wa, 0.0 hi, 0.0 si, 3.2 st
MiB Mem : 1810.699 total, 649.836 free, 797.625 used, 626.777 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 1013.074 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

11951 spam 20 0 252444 175260 7780 S 0.000 9.452 0:00.94 spamd chi+
11953 spam 20 0 224040 149160 9144 S 0.000 8.045 0:00.97 spamd chi+
11950 spam 20 0 222300 147420 9080 S 0.000 7.951 0:01.02 spamd chi+
11954 spam 20 0 221400 146684 9208 S 0.000 7.911 0:00.81 spamd chi+
11955 spam 20 0 220540 145560 9144 S 0.000 7.850 0:00.79 spamd chi+
11947 root 20 0 215304 142068 10552 S 0.000 7.662 0:01.80 spamd
11803 spam 20 0 152632 2972 2484 S 0.000 0.160 0:03.53 gpg-agent
17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:04.16 gpg-agent

Es wird etwas mehr Cache-Speicher eingesetzt, ansonsten ist das relativ konstant. Das war in jüngster Vergangenheit anders. Sollte ich Antispam_Razor wieder aktivieren? Waren am Ende die ins Nirvana laufenden Rule-Updates die Ursache?

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

> Stand heute Morgen: oom-killer hat noch nicht zugeschlagen. Antispam_razor
> ist weiterhin abgeschaltet. Mem-Infos finde ich unauffällig:

Was ist genau antispam_razor?

> 11951 spam 20 0 252444 175260 7780 S 0.000 9.452 0:00.94 spamd
> chi+
> 11953 spam 20 0 224040 149160 9144 S 0.000 8.045 0:00.97 spamd
> chi+
> 11950 spam 20 0 222300 147420 9080 S 0.000 7.951 0:01.02 spamd
> chi+
> 11954 spam 20 0 221400 146684 9208 S 0.000 7.911 0:00.81 spamd
> chi+
> 11955 spam 20 0 220540 145560 9144 S 0.000 7.850 0:00.79 spamd
> chi+
> 11947 root 20 0 215304 142068 10552 S 0.000 7.662 0:01.80 spamd

Ist sogar etwas weniger als vorher.

Vielleicht eben kein Problem mit antispam, sondern mit antispam_razor.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Marcus,

Am 24.10.23 um 10:01 schrieb Marcus Röckrath:

> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>> Stand heute Morgen: oom-killer hat noch nicht zugeschlagen. Antispam_razor
>> ist weiterhin abgeschaltet. Mem-Infos finde ich unauffällig:
>
> Was ist genau antispam_razor?

aus der Paket-Doku:
Vipul's Razor ist ein verteiltes, gemeinschaftliches, Spam-Erkennungs- und Filternetzwerk. Durch Mitwirkung von Anwendern stellt Razor einen verteilten und kontinuierlich aktualisierten Spam-Katalog zur Verfügung, den E-Mail-Programme für die Spam-Filterung verwenden können. Die Erkennung wird durch statistische und zufällige Signaturen, die das effektive Erkennen von sich verändernden Spam-Inhalten ermöglichen, realisiert. Meldungen von Anwendern werden nach deren Reputation und basierend auf übereinstimmende Meldung und Widerrufe beurteilt. Das Ergebnis dieser Auswertungen fließt in die Vertrauensbewertung, und in die Generierung individueller Signaturen für die Anwender ein.

Faktisch ist das eine erweiterte Spam-Erkennung. Es ist gut möglich, dass das damit im Zusammenhang steht. Auf dem anderen Server ist Razor aktiv und der Speicherverbrauch ist deutlich anders:

Anderer Server mit 4GB, Antispam und Antispam-Razor sind aktiv:

23.10.23 08:30 Uhr:
top - 08:30:00 up 14:42, 1 user, load average: 0.21, 0.18, 0.18
Tasks: 161 total, 3 running, 158 sleeping, 0 stopped, 0 zombie
%Cpu(s): 18.8 us, 40.6 sy, 0.0 ni, 15.6 id, 0.0 wa, 0.0 hi, 0.0 si, 25.0 st
MiB Mem : 4020.723 total, 2597.703 free, 832.770 used, 822.020 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 3187.953 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

7902 spam 20 0 254868 171752 8952 S 0.000 4.172 0:04.46 spamd chi+
7898 spam 20 0 251756 168880 8952 S 0.000 4.102 0:05.49 spamd chi+
7901 spam 20 0 251264 168136 8952 S 0.000 4.084 0:03.53 spamd chi+
7899 spam 20 0 243548 160836 8952 S 0.000 3.906 0:03.26 spamd chi+
7903 spam 20 0 241300 158556 8952 S 0.000 3.851 0:03.04 spamd chi+
7353 root 20 0 232508 151280 10352 S 0.000 3.674 0:01.67 spamd
5837 spam 20 0 152632 3144 2656 S 0.000 0.076 0:00.49 gpg-agent
640 redis 20 0 130544 5076 3680 S 0.000 0.123 0:54.62 redis-ser+

24.10.23 11:25 Uhr
top - 11:25:00 up 1 day, 17:37, 2 users, load average: 0.43, 0.32, 0.23
Tasks: 176 total, 2 running, 174 sleeping, 0 stopped, 0 zombie
%Cpu(s): 9.4 us, 31.2 sy, 0.0 ni, 18.8 id, 15.6 wa, 0.0 hi, 0.0 si, 25.0 st
MiB Mem : 4020.723 total, 1729.945 free, 1570.461 used, 959.309 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 2450.262 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

7903 spam 20 0 562536 455628 8892 S 0.000 11.07 0:24.73 spamd chi+
7901 spam 20 0 551328 451732 8952 S 0.000 10.97 0:16.64 spamd chi+
7899 spam 20 0 302660 216992 8952 S 0.000 5.270 0:16.04 spamd chi+
7898 spam 20 0 292068 208544 8952 S 0.000 5.065 0:15.78 spamd chi+
7902 spam 20 0 276232 192520 8888 S 0.000 4.676 0:15.05 spamd chi+
7353 root 20 0 232508 151216 10288 S 0.000 3.673 0:02.25 spamd
13627 root 20 0 169876 4556 0 S 0.000 0.111 0:00.00 (sd-pam)
1 root 20 0 168624 13368 8960 S 0.000 0.325 0:08.53 systemd

Hier ist "used" auffallend.

Ich werde jetzt Razor auf dem 2GB-Server wieder aktivieren.

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Was ist genau antispam_razor?
>
> aus der Paket-Doku:
> Vipul's Razor ist ein verteiltes, gemeinschaftliches, Spam-Erkennungs- und
> Filternetzwerk.
>

> Faktisch ist das eine erweiterte Spam-Erkennung. Es ist gut möglich, dass
> das damit im Zusammenhang steht. Auf dem anderen Server ist Razor aktiv
> und der Speicherverbrauch ist deutlich anders:

Angeblich soll razor.sourceforge.net die offizielle Page von razor sein;
komisch, dass ich hier nur eine leere Seite sehe.

> Anderer Server mit 4GB, Antispam und Antispam-Razor sind aktiv:

> Hier ist "used" auffallend.

Nicht nur das, auch die Werte der spamd-Prozesse sind massiv gestiegen;
prozentual von 25% auf 40%.

> Ich werde jetzt Razor auf dem 2GB-Server wieder aktivieren.

Gut.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Marcus,

Am 24.10.23 um 11:51 schrieb Marcus Röckrath:

>> Ich werde jetzt Razor auf dem 2GB-Server wieder aktivieren.
> Gut.

Jetzt wird's schnell spannend

top - 19:10:00 up 2 days, 5:01, 0 users, load average: 0.28, 0.20, 0.14
Tasks: 147 total, 3 running, 143 sleeping, 0 stopped, 1 zombie
%Cpu(s): 30.0 us, 50.0 sy, 0.0 ni, 16.7 id, 3.3 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 1810.699 total, 138.812 free, 1319.539 used, 616.195 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 491.160 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

30829 spam 20 0 782508 683152 7512 S 0.000 36.84 0:04.00 spamd chi+
30831 spam 20 0 271960 188192 7512 S 0.000 10.15 0:00.41 spamd chi+
30824 spam 20 0 247204 165036 8908 S 0.000 8.901 0:00.61 spamd chi+
30828 spam 20 0 235404 153784 8908 S 0.000 8.294 0:00.47 spamd chi+
30825 spam 20 0 233352 151700 8780 S 0.000 8.182 0:00.45 spamd chi+
30743 root 20 0 229212 149144 10400 S 0.000 8.044 0:01.14 spamd
11803 spam 20 0 152632 2972 2484 S 0.000 0.160 0:04.58 gpg-agent
17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:05.18 gpg-agent


Ich warte darauf, dass es knallt.

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

Ich denke das ist eindeutig; spamasssasin knallt in Verbindung mit razor
(inbesondere auf virtullen Maschinen?) weg.

Ich denke, dass wir hier mit echter Analyse überfordert sind und man sich
möglicherweise direkt mit einem Problembericht bei spamassasin melden muss.

Mir kommt dieses Razor auch etwas merkwürdig (ungepflegt?) vor, denn deren
Website ist gerade nicht lesbar, denn die liefert mir hier auf mehreren
Rechnern und Betriebssystemen nur leere Seiten.

Laut
https://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Plugin_Razor2.html:

Vipul's Razor is a distributed, collaborative, spam detection and filtering
network based on user submissions of spam. Detection is done with
signatures that efficiently spot mutating spam content and user input is
validated through reputation assignments.

Note that Razor2 is disabled by default in init.pre because it is not
available for unlimited free use. It is currently free for personal use,
subject to capacity constraints. See the Cloudmark SpamNet Service Policy
for more details.

Für mich klingt das alles nicht so ganz überzeugend.

Ich mache gleich mal einen parallel Nachfragethread auf, um mal statistisch
die Probleme auf einen Kern zuführen zu können.

--
Gruß Marcus
[eisfair-Team]

[Alexander Bahlo]

Am Tue, 24 Oct 2023 11:51:18 +0200
schrieb Marcus Röckrath <marcus.r...@gmx.de>:

> Angeblich soll razor.sourceforge.net die offizielle Page von razor sein;
> komisch, dass ich hier nur eine leere Seite sehe.

Guckst du in den Browser Developer Tools: GET razor.sourceforge.net /
liefert http/500. Da kann zurzeit nichts kommen.

VG, Alex.

--
Beware of a tall blond man with one black shoe.

[Alexander Bahlo]

Hallo Rolf,

Am Tue, 24 Oct 2023 19:17:32 +0200
schrieb Rolf Bensch <az...@bensch-net.de>:

> Jetzt wird's schnell spannend
>
> top - 19:10:00 up 2 days, 5:01, 0 users, load average: 0.28, 0.20, 0.14
> Tasks: 147 total, 3 running, 143 sleeping, 0 stopped, 1 zombie
> %Cpu(s): 30.0 us, 50.0 sy, 0.0 ni, 16.7 id, 3.3 wa, 0.0 hi, 0.0 si, 0.0 st
> MiB Mem : 1810.699 total, 138.812 free, 1319.539 used, 616.195 buff/cache
> MiB Swap: 0.000 total, 0.000 free, 0.000 used. 491.160 avail Mem
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 30829 spam 20 0 782508 683152 7512 S 0.000 36.84 0:04.00 spamd chi+
> 30831 spam 20 0 271960 188192 7512 S 0.000 10.15 0:00.41 spamd chi+
> 30824 spam 20 0 247204 165036 8908 S 0.000 8.901 0:00.61 spamd chi+
> 30828 spam 20 0 235404 153784 8908 S 0.000 8.294 0:00.47 spamd chi+
> 30825 spam 20 0 233352 151700 8780 S 0.000 8.182 0:00.45 spamd chi+
> 30743 root 20 0 229212 149144 10400 S 0.000 8.044 0:01.14 spamd
> 11803 spam 20 0 152632 2972 2484 S 0.000 0.160 0:04.58 gpg-agent
> 17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:05.18 gpg-agent
>
>
> Ich warte darauf, dass es knallt.

Mag sein, aber in deinem Auszug steht doch nur, dass keiner der
angezeigten Prozesse nennenswert CPU verbraucht, der erste SPAMd braucht
36% Speicher, der zweite 10% und sonst naja... Das war in deiner
vorherigen Übersicht anders: Da brauchten alle SPAMd ~4% Memory. Scheint
vielleicht damit zu tun zu haben, wie SPAMd das Plugin einbindet und was
das Plugin am Ende tut. Vielleicht verhält es sich auch nicht optimal für
SPAMd.

Schön wäre eine chronologische Auflistung nach Prozessen. Zeitlich: sar;
allgemeine Statusübersicht zum Mitgucken atop (letzteres kann top
natürlich gewissermaßen auch). Ich weiß aber leider nicht, welche
Möglichkeiten eisfair mitliefert und was man sich dazu installieren kann.
Die Sache mit dem Cachemem hat Marcus ja schon vollumfänglich
beantwortet, bevor ich reagieren konnte.

Und im Moment kristallisiert sich ja razor raus. Warum razor auf
virtuelle Maschinen besonders reagieren sollte, ist mir allerdings nicht
klar. Möglicherweise gibt es aber auch eine besondere Abhängigkeit zu der
zuletzt herausgefundenen allgemeinen Verfügbarkeitserklärung.

Muss man razor verwenden oder gibt es noch andere Möglichkeiten, etwa
durch eigenhändiges Einbinden von spamlisten - dann kennt man wenigstens
die Quellen. Razor scheint ja "irgendwas" zu machen. Nicht das Spamhaus &
Co viel besser wären, aber die wiedergegebene Beschreibung von razor
klang auch für mich etwas nebulös.

VG, Alex.

--
You will remember, Watson, how the dreadful business of the
Abernetty family was first brought to my notice by the depth which the
parsley had sunk into the butter upon a hot day.
-- Sherlock Holmes

[Marcus Röckrath]

Hallo Alexander,

Alexander Bahlo wrote:

>> Angeblich soll razor.sourceforge.net die offizielle Page von razor sein;
>> komisch, dass ich hier nur eine leere Seite sehe.
>
> Guckst du in den Browser Developer Tools: GET razor.sourceforge.net /
> liefert http/500. Da kann zurzeit nichts kommen.

Wegen Umzug?

https://sourceforge.net/projects/razor/

Zwar Inhalt aber sieht insgesamt auch ziemlich tot aus.

In Mailinglistenarchiv finde ich dann einen Hinweis:

"as razor is owned by cloudmark now you can try a ticket via
https://cloudmark.com/en/support/cloudmark-authority"

Keine Ahnung, wohin man sich nun wegen Razor wirklich wenden soll.

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Alexander,

Alexander Bahlo wrote:

> Schön wäre eine chronologische Auflistung nach Prozessen. Zeitlich: sar;

Wenn du sar dieses Projektes

https://github.com/sysstat/sysstat/

meinst, ist es als sysstat-Paket verfügbar.

> allgemeine Statusübersicht zum Mitgucken atop (letzteres kann top
> natürlich gewissermaßen auch).

atop gibt es bislang nicht, stattdessen neben top z. B. htop oder btop.

> Und im Moment kristallisiert sich ja razor raus. Warum razor auf
> virtuelle Maschinen besonders reagieren sollte, ist mir allerdings nicht
> klar.

Mir auch nicht, und da warte ich auch noch auf Meldungen aus meiner
Umfragemail; vielleicht ist das auch ein falscher Eindruck, wenn z. B. auf
echter Hardware niemand des spamassasin mit razor einsetzt.

--
Gruß Marcus
[eisfair-Team]

[Alexander Bahlo]

Am Tue, 24 Oct 2023 22:44:51 +0200
schrieb Marcus Röckrath <marcus.r...@gmx.de>:

> Alexander Bahlo wrote:
>
> >> Angeblich soll razor.sourceforge.net die offizielle Page von razor sein;
> >> komisch, dass ich hier nur eine leere Seite sehe.
> >
> > Guckst du in den Browser Developer Tools: GET razor.sourceforge.net /
> > liefert http/500. Da kann zurzeit nichts kommen.
>
> Wegen Umzug?

Egal. http/500 = Internal Server Error. Mag zB sein, dass da eine
Applikation hinter steckt, die gerade "nicht kann". Ergebnis ist eine
weiße Seite oder was immer der eingesetzte Webserver darauf als
Fehlerseite parat hat.

--
Don't feed the bats tonight.

[Rolf Bensch]

Am 24.10.23 um 20:02 schrieb Marcus Röckrath:

Hmm, heute Morgen ist die Lage wieder etwas entspannt:

top - 09:45:00 up 2 days, 19:36, 0 users, load average: 0.65, 0.24, 0.13
Tasks: 156 total, 3 running, 153 sleeping, 0 stopped, 0 zombie
%Cpu(s): 50.0 us, 46.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 3.3 st
MiB Mem : 1810.699 total, 404.254 free, 1146.691 used, 523.566 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 664.008 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

30829 spam 20 0 523648 433036 7512 S 0.000 23.35 0:04.41 spamd chi+
30831 spam 20 0 264924 181460 7512 S 0.000 9.787 0:00.73 spamd chi+
30828 spam 20 0 261588 179008 8940 S 0.000 9.654 0:01.36 spamd chi+
30824 spam 20 0 247204 165068 8940 S 0.000 8.903 0:00.89 spamd chi+
30825 spam 20 0 245768 163516 8876 S 0.000 8.819 0:00.81 spamd chi+
30743 root 20 0 229212 149144 10400 S 0.000 8.044 0:01.68 spamd
11803 spam 20 0 152632 2972 2484 S 0.000 0.160 0:06.22 gpg-agent
17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:06.75 gpg-agent

Der Server läuft durch und oom-killer hat noch nicht zugeschlagen.

> Ich denke, dass wir hier mit echter Analyse überfordert sind und man sich
> möglicherweise direkt mit einem Problembericht bei spamassasin melden muss.

Noch ist Platz für konkrete Analysen. Wenn wir denken es liegt an Razor, würde ich das Tool, vor einer offiziellen Anfrage, auf dem Server nochmals deaktivieren. Aber noch warte ich auf oom-killer.

> Mir kommt dieses Razor auch etwas merkwürdig (ungepflegt?) vor, denn deren
> Website ist gerade nicht lesbar, denn die liefert mir hier auf mehreren
> Rechnern und Betriebssystemen nur leere Seiten.

Wenn das Tool nicht mehr gepflegt wird: ich könnte durchaus auch darauf verzichten. Diesen Aufwand mache ich im Moment überwiegend um das Speicherleck zu finden. Die Betriebssicherheit liegt mir am Herzen.

Grüße

Rolf

[Rolf Bensch]

Hallo Alex,

Am 24.10.23 um 22:30 schrieb Alexander Bahlo:

> Und im Moment kristallisiert sich ja razor raus. Warum razor auf virtuelle Maschinen besonders reagieren sollte, ist mir allerdings nicht klar. Möglicherweise gibt es aber auch eine besondere Abhängigkeit zu der zuletzt herausgefundenen allgemeinen Verfügbarkeitserklärung.

Was meinst Du damit? habe ich etwas übersehen?

> Muss man razor verwenden oder gibt es noch andere Möglichkeiten, etwa durch eigenhändiges Einbinden von spamlisten - dann kennt man wenigstens die Quellen. Razor scheint ja "irgendwas" zu machen. Nicht das Spamhaus & Co viel besser wären, aber die wiedergegebene Beschreibung von razor klang auch für mich etwas nebulös.

Man kann auch Spamlisten einbinden. Razor läuft hier seit Jahren mit. Ich könnte aber durchaus auch darauf verzichten.

Grüße

Rolf

[Heinz-Peter Faasen]

Hallo Rolf,

ich finde auffällig, dass ein child-Prozess so nach oben ausbricht.
Gibt es evtl. ein Postfach, das spezielle Rahmenbedingungen hat, etwa
besondere Dateianhänge?
Könntest Du da Nachforschungen anstellen, indem Du die Fächer mal
deaktivierst (evtl. auf anderem Weg abholen, wenn Aktualität sehr wichtig)?

Gruß
Heinz-Peter

[Rolf Bensch]

Hallo Heinz-Peter,

Am 25.10.23 um 10:33 schrieb Heinz-Peter Faasen:

> Hallo Rolf,
>
>> Hmm, heute Morgen ist die Lage wieder etwas entspannt:
>>
>> top - 09:45:00 up 2 days, 19:36,  0 users,  load average: 0.65, 0.24, 0.13
>> Tasks: 156 total,   3 running, 153 sleeping,   0 stopped,   0 zombie
>> %Cpu(s): 50.0 us, 46.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si, 3.3 st
>> MiB Mem : 1810.699 total,  404.254 free, 1146.691 used,  523.566 buff/cache
>> MiB Swap:    0.000 total,    0.000 free,    0.000 used.  664.008 avail Mem
>>
>>    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
>> 30829 spam      20   0  523648 433036   7512 S 0.000 23.35   0:04.41 spamd chi+
>> 30831 spam      20   0  264924 181460   7512 S 0.000 9.787   0:00.73 spamd chi+
>> 30828 spam      20   0  261588 179008   8940 S 0.000 9.654   0:01.36 spamd chi+
>> 30824 spam      20   0  247204 165068   8940 S 0.000 8.903   0:00.89 spamd chi+
>> 30825 spam      20   0  245768 163516   8876 S 0.000 8.819   0:00.81 spamd chi+
>> 30743 root      20   0  229212 149144  10400 S 0.000 8.044   0:01.68 spamd
>> 11803 spam      20   0  152632   2972   2484 S 0.000 0.160   0:06.22 gpg-agent
>> 17998 spam      20   0  152632   2928   2440 S 0.000 0.158   0:06.75 gpg-agent
>>
>> Der Server läuft durch und oom-killer hat noch nicht zugeschlagen.
>
> ich finde auffällig, dass ein child-Prozess so nach oben ausbricht.

ich denke, das könnte die Art und Weise sein, wie razor sich anbindet.

> Gibt es evtl. ein Postfach, das spezielle Rahmenbedingungen hat, etwa besondere Dateianhänge?

Hmmm, wo siehst Du hier einen Zusammenhang zu den Postfächern? Ich sehe das so: wenn hier per smtp eine Mail reinkommt, übergibt sie exim an spamd zur Bewertung. Das Ergebnis wird durch exim in den Mailheader geschrieben, danach liefert exim die Mail aus. M.E. hat spamd keinen regulären Zugriff auf das Postfach. Wie das bei --learnhamspam oder ähnlich aussieht, weiß ich allerdings nicht.

> Könntest Du da Nachforschungen anstellen, indem Du die Fächer mal deaktivierst (evtl. auf anderem Weg abholen, wenn Aktualität sehr wichtig)?

Mails werden hier direkt zugestellt (nicht abgeholt). Beides sind Produktiv-Server weshalb ich nicht einfach ein Postfach abschalten kann. Beide Server habe ca. 10 Postfächer und beide Server haben in etwa das gleiche Problem. Tatsächlich ist auf einem Server ein Postfach sehr groß (11GB). Weil im maildir-Format halte ich ein Problem wegen der Größe aber für nicht sehr wahrscheinlich.

Habe ich einen Denkfehler?

Grüße

Rolf

[Alexander Bahlo]

Am 25.10.23 10:04, schrieb Rolf Bensch:

>Am 24.10.23 um 22:30 schrieb Alexander Bahlo:
>> Und im Moment kristallisiert sich ja razor raus. Warum razor auf virtuelle Maschinen besonders reagieren sollte, ist mir allerdings nicht klar. Möglicherweise gibt es aber auch eine besondere Abhängigkeit zu der zuletzt herausgefundenen allgemeinen Verfügbarkeitserklärung.
>
>Was meinst Du damit? habe ich etwas übersehen?

Eine Spam-Filterung kann SPAMd bereits. Listen verarbeiten sicher auch. Also
muss razor etwas Besonderes leisten. Vielleicht eine Cloud/KI/anderes
Buzzword-basierte Erkennung, die nach der Übernahme durch die neue Firma
mglw mit Api-Key/Zugriffsbeschränkung o.ä. gesichert wird und diese Version
von razor vielleicht damit Schwierigkeiten bekommt? Ist jetzt natürlich nur
ins "Blaue" geraten, aber an so etwas habe ich jedenfalls gedacht.

>Man kann auch Spamlisten einbinden. Razor läuft hier seit Jahren mit. Ich könnte aber durchaus auch darauf verzichten.

Worin besteht der Unterschied zwischen Razor und externen Spamlisten? Oder
trainiert sich Razor nach manuell als Spam-deklarierten Mails? Das liefe
das ja komplett autak und hätte keine Verbindung ins Netz. Wäre klasse,
könnte man sich zwar selbst programmieren, wäre dann aber zumindest ein
echter Mehrwert.

VG, Alex.

[Rolf Bensch]

Hallo Alex,

Am 25.10.23 um 11:45 schrieb Alexander Bahlo:

> Worin besteht der Unterschied zwischen Razor und externen Spamlisten? Oder
> trainiert sich Razor nach manuell als Spam-deklarierten Mails? Das liefe
> das ja komplett autak und hätte keine Verbindung ins Netz. Wäre klasse,
> könnte man sich zwar selbst programmieren, wäre dann aber zumindest ein

Treffer. Zusätzlich mit der Möglichkeit manuell deklarierte Mails in eine öffentliche DB zu bringen.

Grüße

Rolf

[Juergen Edner]

Hallo zusammen,

> Also
> muss razor etwas Besonderes leisten. Vielleicht eine Cloud/KI/anderes
> Buzzword-basierte Erkennung, die nach der Übernahme durch die neue Firma
> mglw mit Api-Key/Zugriffsbeschränkung o.ä. gesichert wird und diese Version
> von razor vielleicht damit Schwierigkeiten bekommt? Ist jetzt natürlich nur
> ins "Blaue" geraten, aber an so etwas habe ich jedenfalls gedacht.

Razor fragt im normalen Betrieb nur einen Score ab, der in die Bewertung
einer Nachricht einfließt, wie dies für viele andere Services auch der
Fall ist. Hierfür baut er eine Verbindung zu einem der verfügbaren
Razor-Backends auf.

Da sich die Serverliste mit der Zeit ändern kann, aktualisiert der
Prozess üblicherweise regelmäßig die Liste der verfügbaren Server. In
der Vergangenheit konnte es hier schon einmal sporadisch zu einem
Problem kommt, sodass versucht wurde einen nicht verfügbaren Server zu
kontaktieren. Sie hierzu die Dateien in
/var/antispam/razor/servers.*.lst. Falls dies der Fall sein sollte, kann
man mittels des Befehls "/usr/bin/razor-admin -discover" manuell eine
Aktualisierung anstoßen.

Falls man die Spam-Einstufung mit seinen eigenen Einstufung unterstützen
will, kann man auf Wunsch Nachrichten an die Razor-Server übermitteln.
Um diese Funktion zu aktivieren, gilt es den Parameter
RAZOR_REPORT_LEARN_FROM_SPAM='yes' zu setzen und einen Account anzulegen.

Hier finden sich weitere Details zur Software:

https://sourceforge.net/projects/razor/support

Gruß Jürgen
PS: Auf meinem "Hardware" Eisfair-Server laufen das antispam- und
antispam_razor-Paket schon seit Jahren ohne Probleme.

--
Mail: jue...@eisfair.org

[Alexander Bahlo]

Hallo Marcus,

> > Schön wäre eine chronologische Auflistung nach Prozessen. Zeitlich: sar;
>
> Wenn du sar dieses Projektes
>
> https://github.com/sysstat/sysstat/
>
> meinst, ist es als sysstat-Paket verfügbar.

Klasse. Ja, ich kenne es nur von RHEL Systemen und
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/4/html/introduction_to_system_administration/s3-resource-tools-sar-sar
zeigt mE ausreichend deutlich auf sysstat und sysstat enthält auch eben
sadc als erforderlicher Daemon, sowie sar als Auslesetool.

Aber ich merke gerade selbst: sar ist nur gut für CPU-Auslastung, mpstat
für Mehrkernsysteme evtl. interessant (hier geht es aber höchstens um die
Belastung eines Threads mit razor, hat nicht unbedingt etwas mit Kernen
zu tun), iostat eben für io (wohl auch für zwischen-CPU), haben wir hier
aber auch nicht in erster Linie als Problem. Es geht ja schließlich um den
Speicherverbrauch.

Rolf meinte noch in einer Frage von Heinz-Peter in Zusammenhang mit dem
Memory-Verbrauch eines einzigen Childs:

>> Gibt es evtl. ein Postfach, das spezielle Rahmenbedingungen hat,
>> etwa besondere Dateianhänge?
>
> Hmmm, wo siehst Du hier einen Zusammenhang zu den Postfächern? Ich sehe
> das so: wenn hier per smtp eine Mail reinkommt, übergibt sie exim an
> spamd zur Bewertung. Das Ergebnis wird durch exim in den Mailheader
> geschrieben, danach liefert exim die Mail aus. M.E. hat spamd keinen
> regulären Zugriff auf das Postfach.

Ich hätte da ggf. einen Zusammenhang in der Einbindung von Razor in Spamd
gesehen. Aber vielleicht hängt es auch einfach damit zusammen, wann
welcher Prozess wie an einer Mail arbeitet. Also sieht zwar etwas komisch
aus, aber ich habe noch keinen ausreichenden Fingerzeig so aus der Ferne.

VG, Alex.

--
Don't hate yourself in the morning -- sleep till noon.

[Rolf Bensch]

Moin zusammen,

Am 25.10.23 um 11:09 schrieb Rolf Bensch:

> Hallo Heinz-Peter,
>
> Am 25.10.23 um 10:33 schrieb Heinz-Peter Faasen:
>> Hallo Rolf,
>>
>>> Hmm, heute Morgen ist die Lage wieder etwas entspannt:
>>>
>>> top - 09:45:00 up 2 days, 19:36, 0 users, load average: 0.65, 0.24, 0.13
>>> Tasks: 156 total, 3 running, 153 sleeping, 0 stopped, 0 zombie
>>> %Cpu(s): 50.0 us, 46.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 3.3 st
>>> MiB Mem : 1810.699 total, 404.254 free, 1146.691 used, 523.566 buff/cache
>>> MiB Swap: 0.000 total, 0.000 free, 0.000 used. 664.008 avail Mem
>>>
>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>> 30829 spam 20 0 523648 433036 7512 S 0.000 23.35 0:04.41 spamd chi+
>>> 30831 spam 20 0 264924 181460 7512 S 0.000 9.787 0:00.73 spamd chi+
>>> 30828 spam 20 0 261588 179008 8940 S 0.000 9.654 0:01.36 spamd chi+
>>> 30824 spam 20 0 247204 165068 8940 S 0.000 8.903 0:00.89 spamd chi+
>>> 30825 spam 20 0 245768 163516 8876 S 0.000 8.819 0:00.81 spamd chi+
>>> 30743 root 20 0 229212 149144 10400 S 0.000 8.044 0:01.68 spamd
>>> 11803 spam 20 0 152632 2972 2484 S 0.000 0.160 0:06.22 gpg-agent
>>> 17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:06.75 gpg-agent
>>>
>>> Der Server läuft durch und oom-killer hat noch nicht zugeschlagen.
>>

Auch heute ist auf dem 2GB Server alles in Ordnung.

top - 07:45:00 up 3 days, 17:36, 0 users, load average: 0.14, 0.11, 0.09
Tasks: 135 total, 1 running, 134 sleeping, 0 stopped, 0 zombie
%Cpu(s): 25.8 us, 41.9 sy, 0.0 ni, 29.0 id, 0.0 wa, 0.0 hi, 0.0 si, 3.2 st
MiB Mem : 1810.699 total, 400.676 free, 1130.035 used, 544.277 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 680.664 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

30829 spam 20 0 523648 433036 7512 S 0.000 23.35 0:04.61 spamd chi+
30831 spam 20 0 264924 183008 8940 S 0.000 9.870 0:01.23 spamd chi+
30828 spam 20 0 253864 171652 8940 S 0.000 9.258 0:01.61 spamd chi+
30824 spam 20 0 247204 165068 8940 S 0.000 8.903 0:01.20 spamd chi+
30825 spam 20 0 243508 161728 8940 S 0.000 8.722 0:01.30 spamd chi+
30743 root 20 0 229212 149144 10400 S 0.000 8.044 0:02.50 spamd
11803 spam 20 0 152632 2972 2484 S 0.000 0.160 0:08.59 gpg-agent
17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:09.06 gpg-agent

Kein Neustart und auch kein oom-killer.

Auch auf dem 4GB-Server gibt es keine Auffälligkeiten. Weil ich diesen aber gestern um 09:20 neu starten musste, ist der vielleicht nicht mehr repräsentativ:

top - 07:55:00 up 22:34, 1 user, load average: 0.14, 0.23, 0.24
Tasks: 168 total, 2 running, 166 sleeping, 0 stopped, 0 zombie
%Cpu(s): 19.4 us, 29.0 sy, 0.0 ni, 25.8 id, 3.2 wa, 0.0 hi, 0.0 si, 22.6 st
MiB Mem : 4020.715 total, 2117.391 free, 1048.879 used, 1095.430 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 2971.836 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

14888 spam 20 0 329252 244256 8896 S 0.000 5.933 0:12.13 spamd chi+
14886 spam 20 0 285432 203060 8896 S 0.000 4.932 0:12.58 spamd chi+
14889 spam 20 0 279532 197424 8896 S 0.000 4.795 0:12.16 spamd chi+
14887 spam 20 0 267252 184156 8896 S 0.000 4.473 0:10.22 spamd chi+
14890 spam 20 0 266016 182936 8896 S 0.000 4.443 0:11.72 spamd chi+
13559 root 20 0 229784 149308 10352 S 0.000 3.626 0:02.25 spamd
3337 spam 20 0 152632 1092 608 S 0.000 0.027 0:00.49 gpg-agent
652 redis 20 0 130544 4988 3604 S 0.000 0.121 1:22.63 redis-ser+

Bis zum 22.10. waren die zeitlichen Differenzen zwischen Neustart und oom-killer deutlich kleiner. Weshalb das aktuell durchläuft... keine Ahnung ... Vorführeffekt?

Die Protokolle laufen weiter.

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

> Bis zum 22.10. waren die zeitlichen Differenzen zwischen Neustart und
> oom-killer deutlich kleiner. Weshalb das aktuell durchläuft... keine
> Ahnung ... Vorführeffekt?

Ich brauche schon seit ewigen Zeiten nicht mehr zum Zahnarzt, denn da sind
die Schmerzen ja sowieso weg. ;-))))))))))))))))))))))))))))

> Die Protokolle laufen weiter.

Ok.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Moin zusammen,

Am 26.10.23 um 08:04 schrieb Rolf Bensch:

> Auch heute ist auf dem 2GB Server alles in Ordnung.
>
> top - 07:45:00 up 3 days, 17:36, 0 users, load average: 0.14, 0.11, 0.09
> Tasks: 135 total, 1 running, 134 sleeping, 0 stopped, 0 zombie
> %Cpu(s): 25.8 us, 41.9 sy, 0.0 ni, 29.0 id, 0.0 wa, 0.0 hi, 0.0 si, 3.2 st
> MiB Mem : 1810.699 total, 400.676 free, 1130.035 used, 544.277 buff/cache
> MiB Swap: 0.000 total, 0.000 free, 0.000 used. 680.664 avail Mem
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 30829 spam 20 0 523648 433036 7512 S 0.000 23.35 0:04.61 spamd chi+
> 30831 spam 20 0 264924 183008 8940 S 0.000 9.870 0:01.23 spamd chi+
> 30828 spam 20 0 253864 171652 8940 S 0.000 9.258 0:01.61 spamd chi+
> 30824 spam 20 0 247204 165068 8940 S 0.000 8.903 0:01.20 spamd chi+
> 30825 spam 20 0 243508 161728 8940 S 0.000 8.722 0:01.30 spamd chi+
> 30743 root 20 0 229212 149144 10400 S 0.000 8.044 0:02.50 spamd
> 11803 spam 20 0 152632 2972 2484 S 0.000 0.160 0:08.59 gpg-agent
> 17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:09.06 gpg-agent
>

auch bis zum 5. Tag kein Absturz. Auch keine nennenswerte Veränderung in der Speichernutzung auf dem 2GB-Server:

top - 08:00:00 up 4 days, 17:51, 0 users, load average: 0.10, 0.10, 0.09
Tasks: 151 total, 2 running, 148 sleeping, 0 stopped, 1 zombie
%Cpu(s): 25.8 us, 48.4 sy, 0.0 ni, 22.6 id, 0.0 wa, 0.0 hi, 0.0 si, 3.2 st
MiB Mem : 1810.699 total, 365.285 free, 1149.410 used, 560.762 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 661.289 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

30829 spam 20 0 523648 434468 8940 S 0.000 23.43 0:05.98 spamd chi+
30831 spam 20 0 264924 183108 8940 S 0.000 9.876 0:02.90 spamd chi+
30824 spam 20 0 255856 173912 8940 S 0.000 9.380 0:02.77 spamd chi+
30828 spam 20 0 253488 171480 8940 S 0.000 9.248 0:03.37 spamd chi+
30825 spam 20 0 245556 163664 8940 S 0.000 8.827 0:03.11 spamd chi+
30743 root 20 0 229212 149144 10400 S 0.000 8.044 0:03.37 spamd
11803 spam 20 0 152632 2976 2484 S 0.000 0.161 0:11.11 gpg-agent
17998 spam 20 0 152632 2928 2440 S 0.000 0.158 0:11.53 gpg-agent

Neuerdings "1 zombie" aber ansonsten absolut stabil.

Ich melde mich wieder wenn's geknallt hat.

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Auch heute ist auf dem 2GB Server alles in Ordnung.

Ich liebe es, wenn Probleme sporadisch auftreten und nicht reproduzierbar
sind. Hatten wir mit dem oom-Killer-Auftreten aber früher auch.

> Neuerdings "1 zombie" aber ansonsten absolut stabil.

Wer ist der Zombi? Wobei Zombies keine Ressourcen mehr belegen.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Marucs,

Am 27.10.23 um 08:26 schrieb Marcus Röckrath:

> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>>> Auch heute ist auf dem 2GB Server alles in Ordnung.
>
> Ich liebe es, wenn Probleme sporadisch auftreten und nicht reproduzierbar
> sind. Hatten wir mit dem oom-Killer-Auftreten aber früher auch.

Nunja, ich hatte das hier etwa ein halbes Jahr reproduzierbar auf 2 Servern.

>> Neuerdings "1 zombie" aber ansonsten absolut stabil.
>
> Wer ist der Zombi?

Keine Ahnung.

mail (/) # ps aux | grep 'Z'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 28548 0.0 0.1 4560 2832 pts/0 S+ 10:36 0:00 /bin/sh /bin/grep Z

Auch andere Tests liefern keine Ausgabe. Top listet weiterhin "1 zombie". Hast Du einen Vorschlag wie ich das ermitteln kann?

Grüße

Rolf

[Marcus Röckrath]

Das ist der Zombi, mal sehen, zu welchem Elternprozess er gehört:

ps faux

Was sagt (nach Installation des zps-Paketes):

zps -l

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Marcus,

Am 27.10.23 um 10:59 schrieb Marcus Röckrath:

> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>>> Wer ist der Zombi?
>>
>> Keine Ahnung.
>>
>> mail (/) # ps aux | grep 'Z'
>> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
>> root 28548 0.0 0.1 4560 2832 pts/0 S+ 10:36 0:00 /bin/sh
>> /bin/grep Z
>>
>> Auch andere Tests liefern keine Ausgabe. Top listet weiterhin "1 zombie".
>> Hast Du einen Vorschlag wie ich das ermitteln kann?
>
> Das ist der Zombi,

Sicher? Das sieht eher nach der Befehlszeile aus, die ich gerade ausgeführt habe.

> mal sehen, zu welchem Elternprozess er gehört:
>
> ps faux

Ziemlich viel output - s.u.

> Was sagt (nach Installation des zps-Paketes):
>
> zps -l

mail (/) # zps -l
PID PPID STATE NAME COMMAND
mail (/) #

Grüße

Rolf

mail (/) # ps faux

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

root 2 0.0 0.0 0 0 ? S Oct22 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [rcu_gp]
root 4 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [rcu_par_gp]
root 5 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [slub_flushwq]
root 6 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [netns]
root 8 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [kworker/0:0H-events_highpri]
root 10 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [mm_percpu_wq]
root 11 0.0 0.0 0 0 ? S Oct22 0:00 \_ [rcu_tasks_trace]
root 12 0.0 0.0 0 0 ? S Oct22 0:30 \_ [ksoftirqd/0]
root 13 0.0 0.0 0 0 ? I Oct22 2:25 \_ [rcu_sched]
root 14 0.0 0.0 0 0 ? S Oct22 0:00 \_ [migration/0]
root 15 0.0 0.0 0 0 ? S Oct22 0:00 \_ [cpuhp/0]
root 16 0.0 0.0 0 0 ? S Oct22 0:00 \_ [cpuhp/1]
root 17 0.0 0.0 0 0 ? S Oct22 0:00 \_ [migration/1]
root 18 0.0 0.0 0 0 ? S Oct22 0:34 \_ [ksoftirqd/1]
root 20 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [kworker/1:0H-events_highpri]
root 21 0.0 0.0 0 0 ? S Oct22 0:00 \_ [kdevtmpfs]
root 22 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [inet_frag_wq]
root 24 0.0 0.0 0 0 ? S Oct22 0:00 \_ [oom_reaper]
root 25 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [writeback]
root 26 0.0 0.0 0 0 ? S Oct22 0:11 \_ [kcompactd0]
root 27 0.0 0.0 0 0 ? SN Oct22 0:00 \_ [ksmd]
root 44 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [kintegrityd]
root 45 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [kblockd]
root 46 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [blkcg_punt_bio]
root 47 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [md]
root 48 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [devfreq_wq]
root 49 0.0 0.0 0 0 ? S Oct22 0:00 \_ [watchdogd]
root 50 0.0 0.0 0 0 ? I< Oct22 0:03 \_ [kworker/0:1H-kblockd]
root 51 0.0 0.0 0 0 ? S Oct22 0:00 \_ [kswapd0]
root 53 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [kthrotld]
root 54 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/24-aerdrv]
root 55 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/25-aerdrv]
root 56 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/26-aerdrv]
root 57 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/27-aerdrv]
root 58 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/28-aerdrv]
root 59 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/29-aerdrv]
root 60 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/30-aerdrv]
root 61 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/31-aerdrv]
root 62 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/32-aerdrv]
root 63 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/33-aerdrv]
root 64 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/34-aerdrv]
root 65 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/35-aerdrv]
root 66 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/36-aerdrv]
root 67 0.0 0.0 0 0 ? S Oct22 0:00 \_ [irq/37-aerdrv]
root 68 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [acpi_thermal_pm]
root 70 0.0 0.0 0 0 ? S Oct22 0:00 \_ [hwrng]
root 71 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [raid5wq]
root 72 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [kstrp]
root 74 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [mld]
root 75 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [ipv6_addrconf]
root 99 0.0 0.0 0 0 ? I< Oct22 0:04 \_ [kworker/1:1H-kblockd]
root 252 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [ata_sff]
root 253 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [cryptd]
root 254 0.0 0.0 0 0 ? S Oct22 0:00 \_ [scsi_eh_0]
root 255 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [scsi_tmf_0]
root 265 0.0 0.0 0 0 ? S Oct22 0:00 \_ [scsi_eh_1]
root 271 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [scsi_tmf_1]
root 273 0.0 0.0 0 0 ? S Oct22 0:00 \_ [scsi_eh_2]
root 274 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [scsi_tmf_2]
root 275 0.0 0.0 0 0 ? S Oct22 0:00 \_ [scsi_eh_3]
root 278 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [scsi_tmf_3]
root 280 0.0 0.0 0 0 ? S Oct22 0:00 \_ [scsi_eh_4]
root 281 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [scsi_tmf_4]
root 283 0.0 0.0 0 0 ? S Oct22 0:00 \_ [scsi_eh_5]
root 285 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [scsi_tmf_5]
root 308 0.0 0.0 0 0 ? S Oct22 0:12 \_ [jbd2/vda2-8]
root 309 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [ext4-rsv-conver]
root 406 0.0 0.0 0 0 ? S Oct22 0:00 \_ [jbd2/vda1-8]
root 407 0.0 0.0 0 0 ? I< Oct22 0:00 \_ [ext4-rsv-conver]
root 10363 0.0 0.0 0 0 ? I 10:52 0:00 \_ [kworker/1:2-events]
root 29834 0.0 0.0 0 0 ? I 11:09 0:00 \_ [kworker/0:0-events]
root 27234 0.0 0.0 0 0 ? I 11:19 0:00 \_ [kworker/u4:1-events_unbound]
root 1247 0.0 0.0 0 0 ? I 11:21 0:00 \_ [kworker/1:3-cgroup_destroy]
root 7269 0.0 0.0 0 0 ? I 11:22 0:00 \_ [kworker/0:3-events]
root 24361 0.0 0.0 0 0 ? I 11:28 0:00 \_ [kworker/u4:2-events_unbound]
root 3487 0.0 0.0 0 0 ? I 11:31 0:00 \_ [kworker/0:1-cgroup_destroy]
root 3508 0.0 0.0 0 0 ? I 11:31 0:00 \_ [kworker/0:2-events_power_efficient]
root 4072 0.0 0.0 0 0 ? I 11:32 0:00 \_ [kworker/1:0-mm_percpu_wq]
root 9315 0.0 0.0 0 0 ? I 11:33 0:00 \_ [kworker/u4:0-ext4-rsv-conversion]
root 1 0.0 0.6 102272 12196 ? Ss Oct22 0:34 /usr/lib/systemd/systemd --switched-root --system --deserialize=31
root 130 0.0 0.2 8448 5156 ? Ss Oct22 0:10 @usr/sbin/haveged -w 1024 -v -1 -F
root 339 0.0 1.9 139400 35640 ? Ss Oct22 0:12 /usr/lib/systemd/systemd-journald
root 354 0.0 0.4 29720 8244 ? Ss Oct22 0:00 /usr/lib/systemd/systemd-udevd
systemd+ 410 0.0 0.3 89960 7224 ? Ssl Oct22 0:02 /usr/lib/systemd/systemd-timesyncd
at 415 0.0 0.1 4004 2364 ? Ss Oct22 0:00 /usr/sbin/atd -f
message+ 416 0.0 0.2 8568 4628 ? Ss Oct22 0:20 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activ
root 417 0.0 0.1 4364 2864 ? Ss Oct22 0:02 /usr/sbin/fcron -f
root 421 0.0 0.0 2700 1100 ? Ss Oct22 0:05 /usr/sbin/syslogd -F -m 20
root 425 0.0 0.4 17148 8032 ? Ss Oct22 0:11 /usr/lib/systemd/systemd-logind
root 428 0.0 0.0 3184 1232 tty1 Ss+ Oct22 0:00 /sbin/agetty -o -p -- \u --noclear - linux
root 433 0.0 0.4 14872 8688 ? Ss Oct22 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-10 startups
root 3538 0.0 0.5 17668 10536 ? Ss 11:32 0:00 \_ sshd: root@pts/0
root 3548 0.0 0.2 5796 4868 pts/0 Ss 11:32 0:00 \_ -bash
root 17921 200 0.1 7748 3332 pts/0 R+ 11:36 0:00 \_ ps faux
root 451 0.0 1.8 111220 34440 ? Ss Oct22 0:24 /usr/sbin/apache2 -k start
wwwrun 456 0.0 1.1 111916 21428 ? S Oct22 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 561 0.0 1.1 111900 22176 ? S Oct22 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 4070 0.0 1.2 111920 23156 ? S Oct22 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 4071 0.0 1.1 111904 21596 ? S Oct22 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 17079 0.0 1.1 111916 21760 ? S Oct23 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 5921 0.0 1.1 111888 21800 ? S Oct23 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 30207 0.0 1.1 111896 21628 ? S Oct26 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 9943 0.0 0.8 111512 16476 ? S 07:57 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 9944 0.0 1.1 111900 21228 ? S 07:57 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 14278 0.0 0.8 111512 16504 ? S 08:51 0:00 \_ /usr/sbin/apache2 -k start
wwwrun 453 0.0 0.0 6328 256 ? Ss Oct22 0:16 /usr/sbin/htcacheclean -d 120 -p /var/lib/apache/diskcache -l 300M -n
redis 666 0.1 0.2 130544 5204 ? Ssl Oct22 13:40 /usr/sbin/redis-server 127.0.0.1:6379
root 1165 0.0 0.0 2684 128 ? SNs Oct22 0:00 /usr/sbin/acpid
root 4720 0.0 0.5 18572 10420 ? Ss Oct22 0:02 /usr/lib/systemd/systemd --user
root 4725 0.0 0.1 21240 3132 ? S Oct22 0:00 \_ (sd-pam)
spam 17998 0.0 0.1 152632 2928 ? Ss Oct22 0:11 gpg-agent --homedir /var/antispam/spamassassin/sa-update-keys --use-standard-socket -
spam 11140 0.0 0.5 18584 10508 ? Ss Oct22 0:02 /usr/lib/systemd/systemd --user
spam 11169 0.0 0.1 21240 3220 ? S Oct22 0:00 \_ (sd-pam)
spam 11803 0.0 0.1 152632 2976 ? Ss Oct22 0:11 gpg-agent --homedir /var/antispam/spamassassin/sa-update-keys --use-standard-socket -
root 30743 0.0 8.0 229212 149144 ? Ss Oct24 0:03 /usr/bin/perl -T -w /usr/sbin/spamd -d -u spam -r /run/antispam/spamd.pid -H /home/sp
spam 30824 0.0 9.1 252632 170520 ? S Oct24 0:03 \_ spamd child
spam 30825 0.0 8.7 244008 162452 ? S Oct24 0:03 \_ spamd child
spam 30828 0.0 9.2 254000 172156 ? S Oct24 0:04 \_ spamd child
spam 30829 0.0 23.4 524160 434980 ? S Oct24 0:06 \_ spamd child
spam 30831 0.0 9.9 265436 183620 ? S Oct24 0:04 \_ spamd child
root 31456 0.0 0.1 4864 2988 ? S Oct24 0:13 /bin/sh /var/install/bin/antispam-control
root 17419 0.0 0.0 3152 1068 ? S 11:36 0:00 \_ sleep 20
root 1684 0.8 0.4 9956 8748 ? S 00:01 5:36 /bin/bash /brute_force_blocking/brute_force_blocking
root 17920 0.0 0.0 3152 1044 ? S 11:36 0:00 \_ sleep 10
exim 9577 0.0 0.4 14772 7712 ? Ss 00:01 0:00 /usr/sbin/exim -bd -q30m -om -oP /run/exim.pid
root 10008 0.0 0.1 5512 3160 ? S 00:01 0:00 /bin/sh /usr/bin/fetchmail-loader start
root 3528 0.0 0.0 3152 1048 ? S 11:31 0:00 \_ sleep 600
root 10552 0.0 0.1 6888 2920 ? Ss 00:01 0:00 /usr/sbin/dovecot -c /etc/dovecot/dovecot.conf
dovecot 10565 0.0 0.0 6576 1572 ? S 00:01 0:00 \_ dovecot/anvil
root 10566 0.0 0.1 6712 3052 ? S 00:01 0:00 \_ dovecot/log
root 10569 0.0 0.2 15080 4676 ? S 00:01 0:00 \_ dovecot/config
dovecot 16391 0.0 0.1 7680 3424 ? S 00:03 0:00 \_ dovecot/stats
dovenull 25377 0.0 0.3 15296 6880 ? S 11:28 0:00 \_ dovecot/imap-login
rolf 25379 0.0 0.2 12712 4652 ? S 11:28 0:00 \_ dovecot/imap
dovenull 25381 0.0 0.3 15296 6900 ? S 11:28 0:00 \_ dovecot/imap-login
rolf 25382 0.0 0.2 12904 4660 ? S 11:28 0:00 \_ dovecot/imap

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Das ist der Zombi,
>
> Sicher? Das sieht eher nach der Befehlszeile aus, die ich gerade
> ausgeführt habe.

Nein, du hast natürlich recht.

>> mal sehen, zu welchem Elternprozess er gehört:
>>
>> ps faux
>
> Ziemlich viel output - s.u.
>
>> Was sagt (nach Installation des zps-Paketes):
>>
>> zps -l
>
> mail (/) # zps -l
> PID PPID STATE NAME COMMAND

Er ist inzwischen weg, in der Prozessliste müsste es eine Zeile mit
(defunct) geben.

Oder zeigt top immer noch einen Zombie an?

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Am 27.10.23 um 12:02 schrieb Marcus Röckrath:

> Er ist inzwischen weg, in der Prozessliste müsste es eine Zeile mit (defunct) geben.

Nein, finde ich nicht

> Oder zeigt top immer noch einen Zombie an?

Nein. Hat sich zwischenzeitlich aufgelöst.

Immer noch kein oom-killer im Logfile zu finden.

Grüße

Rolf

[Nils Lange]

Hallo Marcus,

> Mir auch nicht, und da warte ich auch noch auf Meldungen aus meiner
> Umfragemail; vielleicht ist das auch ein falscher Eindruck, wenn z. B. auf
> echter Hardware niemand des spamassasin mit razor einsetzt.
>

das wird bei mir genutzt, und der Rechner ist echt. Habe diese Probleme
aber nicht festgestellt.

Gruß, Nils

[Nils Lange]

Hallo Rolf,

> Danke für die Info. Ein paar Fragen dazu:
>
> - Blech oder virtualisiert?
> - läuft bei Dir Antispam_razor?

Reine Hardware mit Antispam razor.

> - läuft bei Dir im Antispam-Paket ein "force rules update" fehlerfrei
> durch?
>
Siehe unten.

---gnupg version------------
↑
gpg (GnuPG) 2.3.8
▮
libgcrypt 1.10.1-unknown
a
Copyright (C) 2021 Free Software Foundation, Inc.
a
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
a
This is free software: you are free to change and redistribute it.
a
There is NO WARRANTY, to the extent permitted by law.
a

a
Home: /home/spam/.gnupg
a
Supported algorithms:
a
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
a
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
a
CAMELLIA128, CAMELLIA192, CAMELLIA256
a
AEAD: EAX, OCB
a
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
a
Compression: Uncompressed, ZIP, ZLIB, BZIP2
a

a
---mv gnupg db files--------
a
renamed '/var/antispam/spamassassin/sa-update-keys/pubring.kbx' ->
'/var/antispam/spamassassin/sa-update-keys/pubring.kbx.tmp' a
renamed '/var/antispam/spamassassin/sa-update-keys/pubring.kbx~' ->
'/var/antispam/spamassassin/sa-update-keys/pubring.kbx~.tmp' a
renamed '/var/antispam/spamassassin/sa-update-keys/trustdb.gpg' ->
'/var/antispam/spamassassin/sa-update-keys/trustdb.gpg.tmp' a

a
---downloading gpg key------
a
--2023-10-28 02:37:43-- http://spamassassin.apache.org/updates/GPG.KEY
a
Resolving spamassassin.apache.org (spamassassin.apache.org)...
151.101.2.132 a
Connecting to spamassassin.apache.org
(spamassassin.apache.org)|151.101.2.132|:80... connected.
a
HTTP request sent, awaiting response... 301 Moved Permanently
a
Location: https://spamassassin.apache.org/updates/GPG.KEY [following]
a
--2023-10-28 02:37:43-- https://spamassassin.apache.org/updates/GPG.KEY
a
Connecting to spamassassin.apache.org
(spamassassin.apache.org)|151.101.2.132|:443... connected.
a
HTTP request sent, awaiting response... 200 OK
a
Length: 4777 (4.7K) [application/pgp-keys]
a
Saving to: '/tmp/GPG.KEY'
a

a
0K .... 100%
6.70M=0.001s


28 02:37:44.519 [27165] dbg: logger: adding facilities: all
↑
Oct 28 02:37:44.519 [27165] dbg: logger: logging level is DBG
a
Oct 28 02:37:44.519 [27165] dbg: generic: SpamAssassin version 3.4.4
a
Oct 28 02:37:44.519 [27165] dbg: generic: Perl 5.030001, PREFIX=/usr,
DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/vara
Oct 28 02:37:44.520 [27165] dbg: config: timing enabled
a
Oct 28 02:37:44.520 [27165] dbg: config: score set 0 chosen.
a
Oct 28 02:37:44.527 [27165] dbg: generic: sa-update version 3.4.4 /
svn1869639 a
Oct 28 02:37:44.527 [27165] dbg: generic: using update directory:
/var/antispam/spamassassin/sa-update-files/3.004004 ▮
Oct 28 02:37:44.881 [27165] dbg: diag: perl platform: 5.030001 linux
a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] module installed:
Digest::SHA, version 6.02 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] module installed:
HTML::Parser, version 3.72 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] module installed: Net::DNS,
version 1.24 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] module installed:
NetAddr::IP, version 4.079 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] module installed:
Time::HiRes, version 1.976 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] module installed:
Archive::Tar, version 2.32 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] module installed: IO::Zlib,
version 1.10 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Digest::SHA1, version 2.13 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
MIME::Base64, version 3.15 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
DB_File, version 1.843 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Net::SMTP, version 3.11 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Mail::SPF, version v2.009 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module not
installed: GeoIP2::Database::Reader ('require' failed) a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Geo::IP, version 1.51 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module not
installed: IP::Country::DB_File ('require' failed) a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Net::CIDR::Lite, version 0.21 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Razor2::Client::Agent, version 2.86 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
IO::Socket::IP, version 0.39 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
IO::Socket::INET6, version 2.72 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
IO::Socket::SSL, version 2.068 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Compress::Zlib, version 2.084 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Mail::DKIM, version 0.54 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
DBI, version 1.643 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Getopt::Long, version 2.5 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
LWP::UserAgent, version 6.45 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
HTTP::Date, version 6.05 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Encode::Detect::Detector, version 1.01 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Net::Patricia, version 1.22 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Net::DNS::Nameserver, version 1781 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
BSD::Resource, version 1.2911 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
Archive::Zip, version 1.68 a
Oct 28 02:37:44.881 [27165] dbg: diag: [...] optional module installed:
IO::String, version 1.08 a
Oct 28 02:37:44.883 [27165] dbg: gpg: Searching for 'gpg'
a
Oct 28 02:37:44.883 [27165] dbg: util: current PATH is:
/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin a
Oct 28 02:37:44.883 [27165] dbg: util: executable for gpg was found at
/usr/bin/gpg a
Oct 28 02:37:44.883 [27165] dbg: gpg: found /usr/bin/gpg
a
Oct 28 02:37:44.914 [27165] dbg: gpg: [GNUPG:] KEY_CONSIDERED
5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 0 a
Oct 28 02:37:44.914 [27165] dbg: gpg: [GNUPG:] IMPORTED 4056A61A5244EC45
updates.spamassassin.org Signing Key <release@spamassassa
Oct 28 02:37:44.914 [27165] dbg: gpg: [GNUPG:] IMPORT_OK 1
5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 a
Oct 28 02:37:44.916 [27165] dbg: gpg: [GNUPG:] IMPORT_RES 1 0 1 0 0 0 0
0 0 0 0 0 0 0 0 a

a
---downloading gpg key------
a
--2023-10-28 02:37:45-- http://yerp.org/rules/GPG.KEY
a
Resolving yerp.org (yerp.org)... 71.19.147.22
a
Connecting to yerp.org (yerp.org)|71.19.147.22|:80... connected.
a
HTTP request sent, awaiting response... 200 OK
a
Length: 2437 (2.4K) [application/octet-stream]
a
Saving to: '/tmp/GPG.KEY'
a

a
0K .. 100%
91.1M=0s


---downloading gpg key------
a
--2023-10-28 02:42:27-- https://sa.zmi.at/sa-update-german/GPG.KEY
a
Resolving sa.zmi.at (sa.zmi.at)... 212.69.164.58
a
Connecting to sa.zmi.at (sa.zmi.at)|212.69.164.58|:443... failed:
Connection refused. a


---downloading gpg key------
↑
--2023-10-28 02:42:27-- https://sa.zmi.at/sa-update-german/GPG.KEY
a
Resolving sa.zmi.at (sa.zmi.at)... 212.69.164.58
a
Connecting to sa.zmi.at (sa.zmi.at)|212.69.164.58|:443... failed:
Connection refused. a

a
---restore gnupg db files---
a
renamed '/var/antispam/spamassassin/sa-update-keys/pubring.kbx~.tmp' ->
'/var/antispam/spamassassin/sa-update-keys/pubring.kbx~' a
renamed '/var/antispam/spamassassin/sa-update-keys/trustdb.gpg.tmp' ->
'/var/antispam/spamassassin/sa-update-keys/trustdb.gpg' a

a
---updating channel(s)------
a
Oct 28 02:42:27.809 [13993] dbg: logger: adding facilities: all
a
Oct 28 02:42:27.809 [13993] dbg: logger: logging level is DBG
a
Oct 28 02:42:27.809 [13993] dbg: generic: SpamAssassin version 3.4.4
a
Oct 28 02:42:27.809 [13993] dbg: generic: Perl 5.030001, PREFIX=/usr,
DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/vara
Oct 28 02:42:27.809 [13993] dbg: config: timing enabled
a
Oct 28 02:42:27.810 [13993] dbg: config: score set 0 chosen.
a
Oct 28 02:42:27.815 [13993] dbg: generic: sa-update version 3.4.4 /
svn1869639 a
Oct 28 02:42:27.815 [13993] dbg: generic: using update directory:
/var/antispam/spamassassin/sa-update-files/3.004004 a
Oct 28 02:42:28.080 [13993] dbg: diag: perl platform: 5.030001 linux
a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] module installed:
Digest::SHA, version 6.02 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] module installed:
HTML::Parser, version 3.72 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] module installed: Net::DNS,
version 1.24 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] module installed:
NetAddr::IP, version 4.079 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] module installed:
Time::HiRes, version 1.976 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] module installed:
Archive::Tar, version 2.32 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] module installed: IO::Zlib,
version 1.10 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Digest::SHA1, version 2.13 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
MIME::Base64, version 3.15 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
DB_File, version 1.843 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Net::SMTP, version 3.11 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Mail::SPF, version v2.009 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module not
installed: GeoIP2::Database::Reader ('require' failed) a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Geo::IP, version 1.51 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module not
installed: IP::Country::DB_File ('require' failed) a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Net::CIDR::Lite, version 0.21 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Razor2::Client::Agent, version 2.86 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
IO::Socket::IP, version 0.39 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
IO::Socket::INET6, version 2.72 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
IO::Socket::SSL, version 2.068 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Compress::Zlib, version 2.084 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Mail::DKIM, version 0.54 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
DBI, version 1.643 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Getopt::Long, version 2.5 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
LWP::UserAgent, version 6.45 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
HTTP::Date, version 6.05 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Encode::Detect::Detector, version 1.01 ▮
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Net::Patricia, version 1.22 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Net::DNS::Nameserver, version 1781 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
BSD::Resource, version 1.2911 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
Archive::Zip, version 1.68 a
Oct 28 02:42:28.080 [13993] dbg: diag: [...] optional module installed:
IO::String, version 1.08 a
Oct 28 02:42:28.082 [13993] dbg: gpg: reading in gpgfile
/var/antispam/spamassassin/sa-update-keys/sa-update-trusted-keys.txt a
Oct 28 02:42:28.082 [13993] dbg: gpg: adding key id 5244EC45
a
Oct 28 02:42:28.082 [13993] dbg: gpg: adding key id 6C6191E3
a
Oct 28 02:42:28.082 [13993] dbg: gpg: adding key id 40F74481
a
Oct 28 02:42:28.083 [13993] dbg: gpg: Searching for 'gpg'
a
Oct 28 02:42:28.083 [13993] dbg: util: current PATH is:
/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin a
Oct 28 02:42:28.083 [13993] dbg: util: executable for gpg was found at
/usr/bin/gpg a
Oct 28 02:42:28.083 [13993] dbg: gpg: found /usr/bin/gpg

Oct 28 02:42:28.083 [13993] dbg: gpg: Searching for 'gpg'
a
Oct 28 02:42:28.083 [13993] dbg: util: current PATH is:
/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin a
Oct 28 02:42:28.083 [13993] dbg: util: executable for gpg was found at
/usr/bin/gpg a
Oct 28 02:42:28.083 [13993] dbg: gpg: found /usr/bin/gpg
a
Oct 28 02:42:28.083 [13993] dbg: gpg: release trusted key id list:
6C6191E3 5244EC45 5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 0C2a
Oct 28 02:42:28.083 [13993] dbg: channel: reading in channelfile
/var/antispam/spamassassin/sa-update-channels.txt a
Oct 28 02:42:28.083 [13993] dbg: channel: adding
updates.spamassassin.org
a
Oct 28 02:42:28.083 [13993] dbg: channel: adding sought.rules.yerp.org
a
Oct 28 02:42:28.083 [13993] dbg: channel: adding sa.zmi.at
a
Oct 28 02:42:28.084 [13993] dbg: util: secure_tmpfile created a
temporary file /tmp/.spamassassin13993ksEGqUtmp a
Oct 28 02:42:28.084 [13993] dbg: channel: attempting channel
updates.spamassassin.org a
Oct 28 02:42:28.084 [13993] dbg: channel: using existing directory
/var/antispam/spamassassin/sa-update-files/3.004004/updates_spa
Oct 28 02:42:28.084 [13993] dbg: channel: channel cf file
/var/antispam/spamassassin/sa-update-files/3.004004/updates_spamassassia
Oct 28 02:42:28.084 [13993] dbg: channel: channel pre file
/var/antispam/spamassassin/sa-update-files/3.004004/updates_spamassassa
Oct 28 02:42:28.085 [13993] dbg: channel: metadata version = 1912808,
from file /var/antispam/spamassassin/sa-update-files/3.0040a
Oct 28 02:42:28.096 [13993] dbg: dns: 4.4.3.updates.spamassassin.org =>
1912808, parsed as 1912808 a
Oct 28 02:42:28.097 [13993] dbg: channel: current version is 1912808,
new version is 1912808, skipping channel a
Oct 28 02:42:28.097 [13993] dbg: channel: attempting channel
sought.rules.yerp.org a
Oct 28 02:42:28.097 [13993] dbg: channel: using existing directory
/var/antispam/spamassassin/sa-update-files/3.004004/sought_rula
Oct 28 02:42:28.097 [13993] dbg: channel: channel cf file
/var/antispam/spamassassin/sa-update-files/3.004004/sought_rules_yerp_oa
Oct 28 02:42:28.097 [13993] dbg: channel: channel pre file
/var/antispam/spamassassin/sa-update-files/3.004004/sought_rules_yerp_a
Oct 28 02:42:28.488 [13993] dbg: dns: query failed:
4.4.3.sought.rules.yerp.org => NXDOMAIN
a
Oct 28 02:42:28.972 [13993] dbg: dns: query failed:
mirrors.sought.rules.yerp.org => NXDOMAIN
a
channel 'sought.rules.yerp.org': no 'mirrors.sought.rules.yerp.org'
record found, channel failed a
Oct 28 02:42:28.972 [13993] dbg: channel: attempting channel sa.zmi.at
a
Oct 28 02:42:28.972 [13993] dbg: channel: using existing directory
/var/antispam/spamassassin/sa-update-files/3.004004/sa_zmi_at a
Oct 28 02:42:28.972 [13993] dbg: channel: channel cf file
/var/antispam/spamassassin/sa-update-files/3.004004/sa_zmi_at.cf a
Oct 28 02:42:28.973 [13993] dbg: channel: channel pre file
/var/antispam/spamassassin/sa-update-files/3.004004/sa_zmi_at.pre a
Oct 28 02:42:28.973 [13993] dbg: channel: metadata version = 406, from
file /var/antispam/spamassassin/sa-update-files/3.004004/sa
Oct 28 02:42:28.977 [13993] dbg: dns: 4.4.3.sa.zmi.at => 406, parsed as
406 a
Oct 28 02:42:28.977 [13993] dbg: channel: current version is 406, new
version is 406, skipping channel a
Oct 28 02:42:28.977 [13993] dbg: diag: updates complete, exiting with
code 4 a
---return code: 4-----------

Gruß, Nils

[Marcus Röckrath]

Hallo Nils,

Fein, danke.

Wenn es wirklich nur auf virtualisierten Systemen auftritt, kann es auch am
Virt-Kernel liegen.

Der wird abver auch auf echter Hardware bei E64 genutzt, also müsste es dann
auch auf E64-Hardware-Eis auftreten.

Hast du einen E1 oder E64?

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Nils,

Nils Lange wrote:

>> - läuft bei Dir im Antispam-Paket ein "force rules update" fehlerfrei
>> durch?
>>
> Siehe unten.
>

[...]

> Oct 28 02:42:28.973 [13993] dbg: channel: metadata version = 406, from
> file /var/antispam/spamassassin/sa-update-files/3.004004/sa
> Oct 28 02:42:28.977 [13993] dbg: dns: 4.4.3.sa.zmi.at => 406, parsed as
> 406 a
> Oct 28 02:42:28.977 [13993] dbg: channel: current version is 406, new
> version is 406, skipping channel a
> Oct 28 02:42:28.977 [13993] dbg: diag: updates complete, exiting with
> code 4 a
> ---return code: 4-----------

Ziemlich viel Log gewesen, daher bitte Kurzzusammenfassung: War das
fehlerfrei oder nicht?

Fehlercode ist <> 0.

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo Marcus,

Am 28.10.23 um 09:21 schrieb Marcus Röckrath:

> Ziemlich viel Log gewesen, daher bitte Kurzzusammenfassung: War das fehlerfrei oder nicht? Fehlercode ist <> 0.

Weiter oben ist zu finden:

>> Oct 28 02:42:28.488 [13993] dbg: dns: query failed: 4.4.3.sought.rules.yerp.org => NXDOMAIN

>> Oct 28 02:42:28.972 [13993] dbg: dns: query failed: mirrors.sought.rules.yerp.org => NXDOMAIN

>> channel 'sought.rules.yerp.org': no 'mirrors.sought.rules.yerp.org' record found, channel failed

So war das auch hier auf beiden Servern. Das hatte ich für die Tests bereinigt (URLs deaktiviert). Weil das Speicherproblem nicht mehr auftritt, habe ich gestern auf dem 4GB-Server die fehlerhaften URLs wieder aktiviert - quasi um den Fehler vielleicht zu provozieren. Ist aber bisher nicht aufgetreten. Fehlerhafte URLs scheinen also nicht die Ursache zu sein.

Beide Server laufen, und laufen, und laufen.....

Grüße

Rolf

[Nils Lange]

> Wenn es wirklich nur auf virtualisierten Systemen auftritt, kann es auch am
> Virt-Kernel liegen.
>
> Der wird abver auch auf echter Hardware bei E64 genutzt, also müsste es dann
> auch auf E64-Hardware-Eis auftreten.
>
> Hast du einen E1 oder E64?
>

Ist ein E1. Der existiert schon seit etwa 10 Jahren, wurde damals aus
einem Backup wiederhergestellt, das den Ursprung etwa 2002 hatte.

[Nils Lange]

>
> Ziemlich viel Log gewesen, daher bitte Kurzzusammenfassung: War das
> fehlerfrei oder nicht?
>
> Fehlercode ist <> 0.
>

Folgende URL schlägt fehl:

Resolving sa.zmi.at (sa.zmi.at)... 212.69.164.58

a
Connecting to sa.zmi.at (sa.zmi.at)|212.69.164.58|:443... failed:
Connection refused.

Der Rest läuft durch. Fehlercode gibt es nicht, kann nur mit ---return
code: 4----------- dienen.

Gruß, Nils

[Rolf Bensch]

Hallo zusammen,

Am 27.10.23 um 17:32 schrieb Rolf Bensch:

> Immer noch kein oom-killer im Logfile zu finden.

wegen eines Stromausfall wurde gestern der 2GB-Server neu gestartet. Damit sind die Logfiles in Gänze nicht mehr relevant. Ich kürze sie auf die letzte Startzeit des Server. Nach 20 Stunden Laufzeit liegt die Speicherauslastung (auf beiden Servern) etwa bei 50%.

Hatte mich das Thema seit Ende Februar massiv bis zum 22.10. beschäftigt, ist seitdem kein oom-killer mehr aktiv geworden. Auf beiden Servern! Das kann eigentlich nur im Zusammenhang mit einem "Automatic System Update" stehen (führte ich mind. alle 2 Wochen durch). In /var/log/log.eis-install finde ich aber um den 22.10. nichts worauf ich jetzt mit dem Finger zeigen würde. Das auch deshalb, weil auf beiden Servern grundsätzlich andere Pakete upgedatet wurden.

Weshalb die Server jetzt wieder stabil laufen, ist für mich nicht erklärbar - ich kann damit aber sehr gut umgehen ;-))

Die Logs laufen trotzdem noch weiter.

Grüße

Rolf

[Rolf Bensch]

Hallo zusammen,

Am 02.11.23 um 09:56 schrieb Rolf Bensch:> Hallo zusammen,

Aktueller Sachstand: alle Server laufen wieder stabil. oom-killer hat nicht mehr zugeschlagen. Ich habe die Protokollierung jetzt abgestellt und beerdige hiermit dieses Thema.

Vielen Dank an alle für die Unterstützung

Grüße

Rolf

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

> Aktueller Sachstand: alle Server laufen wieder stabil. oom-killer hat
> nicht mehr zugeschlagen. Ich habe die Protokollierung jetzt abgestellt und
> beerdige hiermit dieses Thema.

Wäre ja nicht das Erstemal, dass die Ursache für das sporadische Auftreten
des oom-Killers nicht festzumachen ist.

--
Gruß Marcus
[eisfair-Team]

[Sascha Pohl]

Hallo zusammen,

Am 04.10.2023 um 23:03 schrieb Sascha Pohl:

> seit geraumer Zeit stelle ich fest, dass antispam irgendwann nicht mehr
> läuft.

nach langer Zeit des Beobachtens und Prüfens habe ich nun neue Erkenntnisse.
Die plötzlichen, unerklärbaren Stopps haben genauso plötzlich aufgehört,
wie sie irgendwann mal begonnen hatten.
Außer den ganzen Updates des gesamten Systems in der ganzen Zeit habe
ich keine weiteren Veränderungen vorgenommen.
Den Logdateien konnte ich keine Begründung entnehmen und einen oom-Kill
konnte ich auch nie finden.
Jetzt habe ich nur noch ein, vermutlich kleines, Problem.
Antispam beendet sich noch immer genau dann, wenn das Logfile rotiert wird.
In der Konfiguration zu logrotate befinden sich dazu folgende Befehle:
SYSLOGD_DEST_2_PREROTATE_CMD=''
SYSLOGD_DEST_2_POSTROTATE_CMD='/etc/init.d/antispam -quiet restart'
Ich meine, vor einiger Zeit in einem anderen Zusammenhang gelesen zu
haben, dass es Probleme gibt, wenn zwei Parameter übergeben werden,
finde es aber im Moment nicht wieder.
Kann dies die Ursache sein?
Und falls ja, wie muss ich die Befehlszeile dann abändern?

Grüße
Sascha

[Marcus Röckrath]

Hallo Sascha,

Sascha Pohl wrote:

>> seit geraumer Zeit stelle ich fest, dass antispam irgendwann nicht mehr
>> läuft.
>
> nach langer Zeit des Beobachtens und Prüfens habe ich nun neue
> Erkenntnisse. Die plötzlichen, unerklärbaren Stopps haben genauso
> plötzlich aufgehört, wie sie irgendwann mal begonnen hatten.

Werden wir damit wohl auch nicht klären können; vielleicht hängt es mit der
Befragung des externen Servers zusammen, was in der antispam-Source nicht
sauber abgefangen wird.

> Jetzt habe ich nur noch ein, vermutlich kleines, Problem.
> Antispam beendet sich noch immer genau dann, wenn das Logfile rotiert
> wird. In der Konfiguration zu logrotate befinden sich dazu folgende
> Befehle: SYSLOGD_DEST_2_PREROTATE_CMD=''
> SYSLOGD_DEST_2_POSTROTATE_CMD='/etc/init.d/antispam -quiet restart'
> Ich meine, vor einiger Zeit in einem anderen Zusammenhang gelesen zu
> haben, dass es Probleme gibt, wenn zwei Parameter übergeben werden,
> finde es aber im Moment nicht wieder.

Ja, das hast du korrekt in Erinnerung; da fehlt noch die richtige Anpassung
an systemd, sprich die Verwendung von service statt direktem Aufruf des
Initskripts in der logrotate-Datei.

Bei letzterem wird durch den Wrapper dann die Kommandozeile unvollständig
genutzt.

Setze im obigen Paramter:

/usr/sbin/service --quiet restart antispam

--
Gruß Marcus
[eisfair-Team]

[Rolf Bensch]

Hallo zusammen,

da ist er wieder:

Dec 25 01:13:20 eis64-3 kernel: Out of memory: Killed process 18115 (sa-learn) total-vm:1753632kB, anon-rss:1661844kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:3576kB oom_score_adj:0

aktuelle Maßnahme: Server aktualisiert.

Ich werde weiter beobachten.

Grüße

Rolf

[Sascha Pohl]

Hallo Marcus,

Am 24.12.2023 um 09:17 schrieb Marcus Röckrath:

> Setze im obigen Paramter:
>
> /usr/sbin/service --quiet restart antispam

Das hat geholfen.
Vielen Dank!
Für mich ist das Problem damit beseitigt und das Thema abgeschlossen.

Grüße
Sascha

[Marcus Röckrath]

Hallo Sascha,

Sascha Pohl wrote:

>> Setze im obigen Paramter:
>>
>> /usr/sbin/service --quiet restart antispam
>
> Das hat geholfen.

Fein.

> Für mich ist das Problem damit beseitigt und das Thema abgeschlossen.

Bis der OOM-Killer wieder kommt. ;-)

--
Gruß Marcus
[eisfair-Team]

[Sascha Pohl]

Hallo Marcus,

Am 30.12.2023 um 08:18 schrieb Marcus Röckrath:

> Bis der OOM-Killer wieder kommt. ;-)

Der hat bei mir nie zugeschlagen.

Grüße
Sascha

[Marcus Röckrath]

Hallo Sascha,

Sascha Pohl wrote:

> Jetzt habe ich nur noch ein, vermutlich kleines, Problem.
> Antispam beendet sich noch immer genau dann, wenn das Logfile rotiert
> wird. In der Konfiguration zu logrotate befinden sich dazu folgende
> Befehle: SYSLOGD_DEST_2_PREROTATE_CMD=''
> SYSLOGD_DEST_2_POSTROTATE_CMD='/etc/init.d/antispam -quiet restart'
> Ich meine, vor einiger Zeit in einem anderen Zusammenhang gelesen zu
> haben, dass es Probleme gibt, wenn zwei Parameter übergeben werden,
> finde es aber im Moment nicht wieder.
> Kann dies die Ursache sein?
> Und falls ja, wie muss ich die Befehlszeile dann abändern?

Habe mir gerade mal das aktuelle antispam-Paket angeschaut und dort finde
ich ein /etc/logrotate.d/antispam-File, welches das logrotate durchführt
und auch schon an service angepasst ist.

Daher ist ein Eintrag für das Rotieren in der logrotate-Konfiguration
unnötig und kontraproduktiv.

Du solltest den Eintrag aus der logrotate-Konfiguration komplett rausnehmen
und schauen, ob du das aktuelle antispam-Paket 2.5.6 installiert hast.

--
Gruß Marcus
[eisfair-Team]

[Sascha Pohl]

Hallo Marcus,

Am 09.01.2024 um 12:15 schrieb Marcus Röckrath:

> Habe mir gerade mal das aktuelle antispam-Paket angeschaut und dort finde
> ich ein /etc/logrotate.d/antispam-File, welches das logrotate durchführt
> und auch schon an service angepasst ist.
>
> Daher ist ein Eintrag für das Rotieren in der logrotate-Konfiguration
> unnötig und kontraproduktiv.
>
> Du solltest den Eintrag aus der logrotate-Konfiguration komplett rausnehmen
> und schauen, ob du das aktuelle antispam-Paket 2.5.6 installiert hast.

es ist nett, dass du dir immernoch Gedanken um das Problem machst.
Ich habe gerade auf meinem Server nachgesehen, ich habe die aktuelle
Version 2.5.6 von antispam installiert.
Allerdings gibt es im Setup keine Möglichkeit den Intervall, zum
Beispiel täglich, wöchentlich, monatlich, für das Logging einzustellen,
so, wie ich es von anderen Paketen kenne.
Außerdem ist in der aktuellen Dokumentation noch immer beschrieben, dass
man zum Rollieren der Logdatei einen Eintrag in der
logrotate-Konfiguration vornehmen soll.
Ich bin nun etwas verwundert.

Grüße
Sascha

[Marcus Röckrath]

Hallo Sascha,

Sascha Pohl wrote:

Ich auch.

Gibt es bei dir in /etc/logrotate.d eine Datei antispam?

Kann sein, dass ich da alten inaktiven Code im Paket gefunden habe.

Ich spreche Jürgen mal intern darauf an.

--
Gruß Marcus
[eisfair-Team]

[Sascha Pohl]

Hallo Marcus,

Am 10.01.2024 um 07:58 schrieb Marcus Röckrath:

> Gibt es bei dir in /etc/logrotate.d eine Datei antispam?

nein, diese Datei gibt es auf meinem Server nicht.

> Ich spreche Jürgen mal intern darauf an.

Danke!

Grüße
Sascha

[Marcus Röckrath]

Hallo Sascha,

Sascha Pohl wrote:

>> Gibt es bei dir in /etc/logrotate.d eine Datei antispam?
> nein, diese Datei gibt es auf meinem Server nicht.
>
>> Ich spreche Jürgen mal intern darauf an.
> Danke!

Also: Du hast recht, der Anwender muss den Eintrag für das Rotieren des Logs
selbst vornehmen.

Ich bin da altem, aber inaktivem Code, aufgesessen.

Jürgen hat die Doku angepasst, so dass Post/Pre-Commands zu service/systemdd
passen, so wie wir das auch hier im Thread besprochen haben.

Somit wäre das geklärt.

--
Gruß Marcus
[eisfair-Team]