Fixed // Postfix: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused

UCS - Univention Corporate Server
, , ,
#1

Betreibe einen UCS-Mail Server mit Kopano (4.4-2 errata385 - und den dazu angebotenen Kopano Patchlevel).

Gestern hatte ich gesehen, dass beim UCS System-Test via Web-Management eine meldung angezeigt wurde. Lösung sollte sein, das man dieses Paket neu installiert. zu meiner Schande muss ich sagen - ich habe vergessen um welches Paket es sich gehandelt hat. Ich meine es hatte etwas mit IP und Perl zu tun.
Nach der Installation habe ich den Server neu gestartet und via MX-Tools den Mail-Empfang getestet. Leider habe ich nicht wirklich eine eMail versendet (rein/raus), da ich ansonsten gesehen hätte, dass alle Nachrichten von Postfix “festgehalten” werden.

Nachdem dann immer noch keine Nachrichten angekommen sind, habe ich mir das mail.log einmal angesehen. Hier findet man viele Nachrichten wie:

connect to 127.0.0.1[127.0.0.1]:10024: Connection refused

In der Datei mail.err findet man die folgende Meldung (passend zu dem Zeitpunkt wo ich das Paket “repariert” habe):

Dec 30 16:09:38 ucs3 spamd[7075]: Can’t locate Mail/SpamAssassin/CompiledRegexps/body_0.pm in @INC (you may need to install the Mail::SpamAssassin::CompiledRegexps::body_0 module) (@INC contains: /var/lib/spamassassin/compiled/5.024/3.004002 /var/lib/spamassassin/compiled/5.024/3.004002/auto /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 1609) line 1.

Habe mir nun einige Einträge im Forum angesehen - die aber leider bisher noch keine Lösung gebracht haben (u.A. Problem: Postfix Error 4.4.1 - message deferred - wo nach dem Neustart des Services sich leider die *.db Dateien dann auch nicht mehr selber neu erzeugt haben - sieht für mich erst mal so aus, als wenn das eine Verschlechterung ist).

Was kann ich tun damit die derzeit rund 200 eMails in die entsprechenden Postfächer geleitet werden?

Freue mich auf eure Unterstützung.

Problem bei Update auf 4.4-8
Fehlermeldung in Mail Log-Dateien (Postfix/Kopano)
#2

TO ADD:

ucs3:/# systemctl start spamassassin.service
Failed to start spamassassin.service: Unit spamassassin.service is masked.

#3

Ich weiß nicht wieso spamassassin bei diur deaktiviert ist. Es zu aktivieren sollte aber nichts das Problem sein:

systemctl unmask spamassassin.service
systemctl start spamassassin.service
#4

Danke für die schnelle Rückmeldung.

systemctl unmask spamassassin.service
–> Rückmeldung --> Removed /etc/systemd/system/spamassassin.service.

systemctl start spamassassin.service
systemctl status spamassassin.service
● spamassassin.service
Loaded: loaded (/etc/init.d/spamassassin; generated; vendor preset: enabled)
Active: active (exited) since Tue 2019-12-31 16:00:12 CET; 17s ago
Docs: man:systemd-sysv-generator(8)
Process: 15342 ExecStart=/etc/init.d/spamassassin start (code=exited, status=0
CPU: 7ms

Dec 31 16:00:12 vmucs42-rd3 systemd[1]: Starting spamassassin.service…
Dec 31 16:00:12 vmucs42-rd3 systemd[1]: Started spamassassin.service.

Zumindest scheint der Service wieder zu laufen :wink:

Leider kommen immer noch keine eMails an - noch gehen welche raus - und die Meldung im mail.log bleibt weiterhin:

connect to 127.0.0.1[127.0.0.1]:10024: Connection refused

Unter “/var/lib/amavis/db” stehen weiterhin keine Dateien.

Ist zwingend ein Neustart des Servers - oder einiger Services erforderlich?

#5

Das ist wohl ein Problem von Postfix und amavisd

EDIT: AFAIK verbindet sich der Amavisd mit dem Spamassasin. Da letzteres wieder läuft, reicht vielleicht ein Neustart aus:

systemctl restart amavis
systemctl restart postfix
#6

Schade - hat leider auch keine Besserung gebracht - werde es nun erst einmal mit einem Server/System Neustart versuchen.

PS: Wird wohl kein guter Start ins neue Jahr ;-(((

#7

Gibts nicht mehr Logs?

EDIT: Du kannst das Schlangenöl auch erstmal deaktivieren:

ucr set mail/antivir/spam='no'
systemctl restart postfix
#8

Habe erst einmal geschaut wie denn der aktuelle Wert lautet - den habe ich gar nicht.

Lautet der in verbindung mit Kopano anders - oder gibt es den gar nicht?

#9

Keine Ahnung. Ich kenne Kopano nicht und weiß daher auch nicht ob es überhaupt in irgendeiner Form auf den UCS-Mailstack aufsetzt.

#10

Habe noch eine “Fehlermeldung” in mail.warn gefunden. Die ist scheinbar auch erst seit gestern da.

Dec 31 17:17:50 ucs3 kopano-spooler[517]: HrLogon server “default:” user “SYSTEM”: network error
Dec 31 17:17:50 ucs3 kopano-spooler[517]: Unable to open admin session: network error (80040115)
Dec 31 17:17:50 ucs3 kopano-spooler[517]: Server connection lost. Reconnecting in 3 seconds…
Dec 31 17:17:51 ucs3 kopano-spooler[517]: gsoap connect: ()
Dec 31 17:17:51 ucs3 kopano-spooler[517]: HrLogon server “default:” user “SYSTEM”: network error
Dec 31 17:17:51 ucs3 kopano-spooler[517]: Unable to open admin session: network error (80040115)
Dec 31 17:17:54 ucs3 kopano-spooler[517]: gsoap connect: ()

Vielleicht hilft das ja noch weiter?

#11

Kopano nutzt in der Tat den normalen Mailstack von UCS.

sofern das Problem die fehlenden Regeln sind, so wurde das Thema schon einige male hier im Forum diskutiert. z.B. in Strange problem with mailserver here oder Problem: Postfix Error 4.4.1 - message deferred

#12

Den Artikel hatte ich auch bereits gesehen und ausprobiert - leider ohne Erfolg - siehe weiter oben. Seit dem habe ich auch keine *.db mehr ;-))

#13

Ich bekomme den Service nicht aus dem (exited) Status raus:

ucs3:~# systemctl status amavis.service
● amavis.service - LSB: Starts amavisd-new mailfilter
Loaded: loaded (/etc/init.d/amavis; generated; vendor preset: enabled)
Active: active (exited) since Tue 2019-12-31 17:17:43 CET; 2h 56min ago
Docs: man:systemd-sysv-generator(8)
Process: 884 ExecStart=/etc/init.d/amavis start (code=exited, status=0/SUCCESS
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/amavis.service

Dec 31 17:17:43 ucs3 systemd[1]: Starting LSB: Starts amavisd-new mailfil
Dec 31 17:17:43 ucs3 systemd[1]: Started LSB: Starts amavisd-new mailfilt

Das Script ./spamassassin habe ich unter “/etc/cron.daily/” ausgeführt. Eine Rückmeldung gab es nicht.

PS: Habe auch “systemctl stop amavis.service” und danach noch einmal ein “systemctl start amavis.service” ausgeführt - leider ohne Verbesserungen.

#14

Ich gehe im Moment davon aus, dass das Problem etwas mit den benötigten *.db Dateien zu tun hat - die sich bei mir leider nicht durch einen Neustart des Services erzeugen lassen.

Solution (die bei mir nicht funktioniert hat)

The Amavis database seems to be corrupted. Fortunately this is easy to repair. Backup the old database - just in case - and delete it.

root@ucs-mail:~# systemctl stop amavis.service
root@ucs-mail:~# cd  /var/lib/amavis/db/
root@ucs-mail:/var/lib/amavis/db/# tar -cjvf ~/amavis_db_backup.tar.bz2 * --remove-files
root@ucs-mail:~# systemctl start amavis.service

When you look into the /var/log/mail.log you will (hopefully) recognize how the new Amavis database is created and postfix starts to roll the e-mails.

Hat einer eine Idee?

#15

Frohes neues Jahr erst einmal ! ! !

Aktueller Status ist, dass Mails zwar in Postfix gehalten werden.

Mögliche Baustellen/Ursachen die bisher aufgefallen sind:

  1. Der “amavis.service” startet nicht richtig --> “exited”

ucs3:~# systemctl status amavis.service
● amavis.service - LSB: Starts amavisd-new mailfilter
Loaded: loaded (/etc/init.d/amavis; generated; vendor preset: enabled)
Active: active (exited) since Tue 2019-12-31 17:17:43 CET; 2h 56min ago
Docs: man:systemd-sysv-generator(8)
Process: 884 ExecStart=/etc/init.d/amavis start (code=exited, status=0/SUCCESS
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/amavis.service

  1. Problem mit der Amavis Database unter “/var/lib/amavis/db”. Gehe hier davon aus, dass wenn sich der Service wieder starten lässt, auch die “*.db” Dateien wieder erzeugt werden.

  2. Auch der “spamassassin.service” startet nicht richtig --> “exited”

● spamassassin.service
Loaded: loaded (/etc/init.d/spamassassin; generated; vendor preset: enabled)
Active: active (exited) since Tue 2019-12-31 17:17:44 CET; 17h ago
Docs: man:systemd-sysv-generator(8)
Process: 876 ExecStart=/etc/init.d/spamassassin start (code=exited, status=0/S
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/spamassassin.service

  1. Fehlermeldung in der “mail.err” Datei zum Zeitpunkt seit dem es Probleme gibt

Dec 30 16:09:38 ucs3 spamd[7075]: Can’t locate Mail/SpamAssassin/CompiledRegexps/body_0.pm in @INC (you may need to install the Mail::SpamAssassin::CompiledRegexps::body_0 module) (@INC contains: /var/lib/spamassassin/compiled/5.024/3.004002 /var/lib/spamassassin/compiled/5.024/3.004002/auto /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 1609) line 1.

  1. “SirTux” hatte noch einen Workaround vorgeschlagen wie erst einmal die eMail ohne den SPAM Part wieder zugestellt werden --> “ucr set mail/antivir/spam=‘no’”. Ich finde jedoch in der UCS Registry hierzu keinen Eintrag:
    grafik
    Kann man den Wert trotzdem setzen und schafft damit einen möglichen Workaround?

Lasst das Jahr gut starten - freue mich über Lösungsvorschläge
Vielen Dank vorab

#16

Ja kann man. Schlimmstenfalls bewirkt er nichts. Aber probier es besser mal mit

ucr set mail/antivir=no

Die Variable ist mir gestern leider nicht aufgefallen. Sie wird vermutlich eher dazu geeignet sein das ganze Schlagenöl zu deaktivieren. mail/antivir/spam ist vermutlich nur für Spamassassin zuständig.

#17

Habe nun folgendes gemacht:

ucr set mail/antivir=no
systemctl restart postfix

Eine neue eMail aus Kopano wurde nach Extern ausgeliefert. Eine externe eMail konnte in Kopano empfangen werden. Fatchmail Nachrichten funktionieren ebenfalls wieder.

Die bisher “gefangenen” (rund 250) bewegen sich jedoch nicht.

Halber Workaround - klasse und Danke schon mal dafür

#18

Die “gefangenen” sollten nach und nach freigelassen werden. Sonst kannst du auch alles auf einen Rutsch freilassen:

Frohes neues übrigens!

#19

Ich hatte es bereits mit “postqueue -f” versucht.

Folgende Meldungen in der “mail.warn”:

Jan 1 11:04:00 ucs3 postfix/qmgr[27513]: warning: connect to transport private/smtp-amavis: Connection refused

Folgende Meldungen in der “mail.log” (Beispiel):

Jan 1 11:07:50 ucs3 postfix/error[27890]: 371A3501D71: to=ANWENDER@DOMAIN.de, orig_to=systemmail@DOMAIN.local, relay=none, delay=125929, delays=125928/0.27/0/0.07, dsn=4.3.0, status=deferred (mail transport unavailable)

Und beim Abfragen via “postqueue -p” steht ebenfalls die Meldung:

F3D1F504049 1120 Tue Dec 31 08:39:01 root@ucs4.dreger-net.local (mail transport unavailable)

Die Mail Queue sieht derzeit so aus (qshape deferred) - und wird auch nicht kleiner:
grafik

#20

Frohes neues Jahr!

Hast du mal versucht, via update_sa die Regeln vom Spamassassin neu runterzuladen?
Das klingt ein wenig danach, dass die Regeln kaputt sind. Amavis lädt diese Regeln (die Perlmodule vom Spamassassin) direkt in seinem Prozess. Sind die Regeln kaputt, kann der Amavis auch nicht starten.

Viele Grüße,

Sönke Schwardt-Krummrich

Mastodon