Postfix nimmt keine Mails mehr an?

W

Wirus

Registered User
Hi,

ich habe seit einigen Tagen ein Problem mit meinem S4Y vserver basic (SuSe 9.3). Bis Vorgestern hatte ich Probleme mit dem Empfangen von Mail, wenn der Server/Postfix ein paar Stunden gelaufen ist (vorher war alles OK). Irgendwann konnten die Mails dann aber nicht mehr zugestellt werden. Nach einem Reboot war alles wieder OK für ein paar Stunden. Seit gestern helfen aber nichtmals mehr die Reboots, was schon ärgerlich ist ;-) Im mail.err habe ich diese Meldung entdeckt:

Code: 
Jan 30 20:05:07 vs149084 postfix/cleanup[27720]: fatal: fstat flow pipe write descriptor: Value too large for defined data type
Jan 30 20:05:08 vs149084 postfix/smtpd[27707]: fatal: unable to connect to the public cleanup service

in der Mail.warn jenes:

Code: 
Jan 30 20:09:17 vs149084 postfix/smtpd[3226]: warning: database /etc/postfix/access.db is older than source file /etc/postfix/access
Jan 30 20:09:17 vs149084 postfix/smtpd[3229]: warning: database /etc/postfix/canonical.db is older than source file /etc/postfix/canonical
Jan 30 20:09:17 vs149084 postfix/smtpd[3229]: warning: database /etc/postfix/access.db is older than source file /etc/postfix/access
Jan 30 20:09:17 vs149084 postfix/cleanup[3237]: warning: database /etc/postfix/canonical.db is older than source file /etc/postfix/canonical
Jan 30 20:09:17 vs149084 postfix/cleanup[3237]: fatal: fstat flow pipe write descriptor: Value too large for defined data type
Jan 30 20:09:18 vs149084 postfix/smtpd[3226]: warning: premature end-of-input on public/cleanup socket while reading input attribute name
Jan 30 20:09:18 vs149084 postfix/smtpd[3226]: fatal: unable to connect to the public cleanup service
Jan 30 20:09:18 vs149084 postfix/master[26149]: warning: process /usr/lib/postfix/cleanup pid 3237 exit status 1
Jan 30 20:09:18 vs149084 postfix/master[26149]: warning: /usr/lib/postfix/cleanup: bad command startup -- throttling
Jan 30 20:09:19 vs149084 postfix/master[26149]: warning: process /usr/lib/postfix/smtpd pid 3226 exit status 1

Postfix läuft ne weile und nach ein paar Minuten beendet sich der Dienst anscheinend (postfix stop bringt die Meldung dass der Dienst nicht läuft...postfix start startet ihn dann?!)

Problem für mich ist jetzt:

1. Behebung ;)
2. Was ist passiert? Da ich seit Monaten nix an meinem Server verändert habe (ausser Standard-Updates per you)

Habt Ihr vielleicht eine Ahnung, was das sein könnte?

Danke :)

Marc
 
Wirus said:
postfix/cleanup[27720]: fatal: fstat flow pipe write descriptor
postfix/smtpd[27707]: fatal: unable to connect to the public cleanup service
Click to expand...
Ich tippe darauf, daß der cleanup-Service wegen Speicherproblemen sich verabschiedet.
Ein "/etc/init.d/postfix restart" sollte erstmal wieder Abhilfe schaffen.
Langfristig solltest Du mal Deine Beancounter anschauen.

warning: database /etc/postfix/access.db is older than source file /etc/postfix/access
warning: database /etc/postfix/canonical.db is older than source file /etc/postfix/canonical[/QUOTE]
Du solltest mal "postmap access" und "postmap canonical" laufen lassen.

huschi.
 
@Wirus:

Hi,

well we found a serious bug in all x86_64 bit kernels from SWsoft. Let
me explain what happened and how we find it.

First we found that some customers complaints about his non working
postfix. After a while more and more customers complaints about that.

We searched some hours to check whats going on and we were not able to
reproduce this, the postfix/cleanup services died with:

Jan 25 17:43:10 vs2061192 postfix/cleanup[22507]: fatal: fstat flow pipe write descriptor: Value too large for defined data type
Jan 25 17:43:11 vs2061192 postfix/smtpd[22281]: fatal: unable to connect to the public cleanup service

The VE 2061192 is located on 10.0.1.80 with latest stable kernel. Well
the customer uses exactly the same templates (no updates are done) like
VE 2060143 on same hostnode, but VE 2060143 works and VE 2061192 not.

The VE is a 32-bit VE and the glibc is a 32-bit glibc, also the postfix
is 32-bit compiled. After some strace we found that the kernel gives the
glibc some 'st_ino' information which is out of range for 32-bit.

vs2061192:~ # grep -B 2 -A 2 "fstat64(4," /postfix.22507
time(NULL) = 1169743390
write(5, "\353W\0\0\10\0\0\0\0\0\0\0", 12) = 12
fstat64(4, {st_dev=makedev(0, 7), st_ino=5088369662, st_mode=S_IFIFO|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0,
+st_atime=2007/01/25-17:41:57, st_mtime=2007/01/25-17:41:57, st_ctime=2007/01/25-17:41:57}) = 0
++++++++++
Value is out of range

And here are for example values which are correct for the same
postfix/cleanup process.

vs2061192:~ # grep "fstat64" /postfix.22507
fstat64(7, {st_dev=makedev(0, 69), st_ino=186995058, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=56, st_size=25546,
+st_atime=2007/01/19-19:58:29, st_mtime=2007/01/19-19:58:29, st_ctime=2007/01/19-19:58:29}) = 0
fstat64(7, {st_dev=makedev(0, 69), st_ino=189731496, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=2048, st_blocks=412, st_size=208228,
+st_atime=2007/01/11-14:21:48, st_mtime=2005/03/19-21:42:11, st_ctime=2007/01/11-14:21:48}) = 0
fstat64(7, {st_dev=makedev(0, 69), st_ino=189731492, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=2048, st_blocks=100, st_size=48792,
+st_atime=2007/01/11-14:21:48, st_mtime=2005/03/19-21:42:11, st_ctime=2007/01/11-14:21:48}) = 0
fstat64(7, {st_dev=makedev(0, 69), st_ino=189731696, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=2048, st_blocks=104, st_size=49396,
+st_atime=2007/01/11-14:21:48, st_mtime=2005/03/19-20:08:24, st_ctime=2007/01/11-14:21:48}) = 0
fstat64(7, {st_dev=makedev(0, 69), st_ino=189731818, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=2048, st_blocks=172, st_size=85892,
+st_atime=2007/01/11-14:21:48, st_mtime=2005/03/19-21:29:11, st_ctime=2007/01/11-14:21:48}) = 0
fstat64(7, {st_dev=makedev(0, 69), st_ino=189731872, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=2048, st_blocks=436, st_size=220185,
+st_atime=2007/01/11-14:21:48, st_mtime=2005/03/19-20:48:02, st_ctime=2007/01/11-14:21:48}) = 0
fstat64(7, {st_dev=makedev(0, 69), st_ino=189731194, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=2048, st_blocks=2268, st_size=1153177,
+st_atime=2007/01/11-14:21:48, st_mtime=2005/03/19-20:48:02, st_ctime=2007/01/11-14:21:48}) = 0

All the 'st_ino' values are in range of 32-bit so the glibc can handle
such case. I have attached all the strace logs from the following command
call:

$ strace -v -o /postfix -ff /usr/sbin/postfix /usr/lib/postfix/master

This is a very special issue, but it is definitely a wrong kernel
behaviour to give a 32-bit glibc some value which is out of range. Also
for us this is an critical issue, because this affects all our
distributions and all the 64-bit hostnodes, especially the hostnode
which are full with customers. Also this issue can hit every
application and we have some more customers with that issue on different
64-bit kernels, so we think this issue is related to all x86_64 kernels.

Das ist eine 1:1 Kopie der Mail die ich SWsoft geschickt habe, ich habe das auch im Kernel schon fixen lassen und update nach und nach die Server und migrier die Kunden um, also noch ein wenig Geduld.

Das Problem wird weiterhin hier diskutiert:

LKML: Jeff Layton: [PATCH 0/3] i_ino uniqueness: alternate approach -- hash the inodes
 
@Huschi: Danke. Ich habe postmap mal ausgeführt ;)

@mbroemme: Da bin ich ja froh, dass ich nicht der einzige bin...war nämlich schon am verzweifeln, ob ich schlaf...öhm...konfiguriere :D Da warte ich jetzt einfach mal und hoffe, dass keine Mails verloren gehen.

Danke und bis denne,

Marc
 
Hi,
@mbroemme:
ich will ja nicht nerven, aber so langsam wäre es schön, wenn der Dienst wieder laufen würde. Ich habe mittlerweile seit Tagen keine Mails bekommen und der Wiederzustellungszeitraum der zustellenden Server ist garantiert bei vielen schon Abgelaufen. Gibt es einen Zeitpunkt, wann mein Server umgestellt wird? Solangsam wärs schön :)

Danke.
 
@mbroemme:
Vielen Dank, dass Du hier die Situation so detailliert beschreibst - unter der ich (oder besser mein vServer bei Euch) auch leide.

Ich hatte mich zwischenzeitlich sogar mal kurz mit Fedora und Sendmail angefreundet, aber nachdem ich meinen MX-Eintrag auf einen anderen Anbieter umgebogen habe bin ich jetzt wieder auf Debian umgestiegen.

Für mich (und vielleicht auch die anderen Betroffenen) wäre es jetzt schön zu wissen, was wir denn tun können bzw. nicht tun sollten.
Denn ich habe gestern meinen vServer neu aufsetzen lassen und spiele derzeit die benötigte Software wieder ein. Wird der von Dir angesprochene Patch auch in das Debian-Image eingespielt oder ist nach einer Neuinstallation wieder der Patch anzuwenden? Kann ich den Patch selber anwenden?

Viele Grüße,
Andreas


Update: Mein vServer ist laut Support-Ticket auf ein anderes Hostsystem umgezogen - und jetzt funktioniert Postfix wieder!
Insgesamt hat die Ticketbearbeitung bei Server 4 You gut geklappt. Also an dieser Stelle mal ein Lob.

Viele Grüße,
Andreas
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top