Gleichzeitiger Abruf mehrere Mail-Konten schlägt fehl

M

mareit

Registered User
Hallo Mail-Experten,

ich stehe auf meinem Vserver bei strato einem Phänomen gegenüber, dass ich mir nicht erklären kann. Auf dem Server laufen 4 Domains mit jeweils einigen E-Mail Konten.

Nach zwei Jahren Betrieb unter Suse 9.3, Plesk 7.5 habe ich den Server neu aufgesetzt mit Suse 10.1, Plesk 8.2.1. Vorher habe ich die Domänen mit Plesk-Backup gesichert und anschließend zurückgespielt. Hat alles funktioniert, alle Konten sind wieder da.

Dann ist mir Folgendes aufgefallen. Die Mails rufe ich mit Mozilla Thunderbird ab. Wenn ich jedes der 5 e-mail-Konten einer Domäne einzeln abrufe funktioniert alles problemlos. Wenn ich die Thunderbirdfunktion "Alle Konten abrufen" nutze, meldet Thunderbird eine Fehlermeldung des Servers, die allerdings leer ist.

Dann habe ich mir für die beiden Abfrageverfahren einmal die mail.info auf dem Server angesehen.

Alle Konten einzeln abgefragt:
Code: 
Dec 21 21:13:10 h123456 pop3d:
Dec 21 21:13:10 h123456 pop3d: IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=testaccount, ip=[84.137.251.25]
Dec 21 21:13:12 h123456 pop3d:
Dec 21 21:13:12 h123456 pop3d: IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=agr, ip=[84.137.251.25]
Dec 21 21:13:15 h123456 pop3d:
Dec 21 21:13:15 h123456 pop3d: IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=info, ip=[84.137.251.25]
Dec 21 21:13:17 h123456 pop3d:
Dec 21 21:13:17 h123456 pop3d: IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=webmaster, ip=[84.137.251.25]
Dec 21 21:13:20 h123456 pop3d:
Dec 21 21:13:20 h123456 pop3d: IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=postmaster, ip=[84.137.251.25]
Alles scheint in Ordnung zu sein.
Dann alle Konten "in einem Rutsch abgefragt":
Code: 
Dec 21 21:17:24 h123456 pop3d: IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=webmaster, ip=[84.137.251.25]
Dec 21 21:17:24 h123456 pop3d: IMAP connect from @ [84.137.251.25]IMAP connect from @ [84.137.251.25]IMAP connect from @ 
[84.137.251.25]ERR:
Dec 21 21:17:24 h123456 pop3d: LOGIN, user=testaccount, ip=[84.137.251.25]
Dec 21 21:17:24 h123456 pop3d: LOGIN, user=postmaster, ip=[84.137.251.25]
Dec 21 21:17:24 h123456 pop3d:
Dec 21 21:17:29 h123456 pop3d:
Dec 21 21:17:29 h123456 pop3d: IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=webmaster, ip=[84.137.251.25]
Um sicher zu gehen, der gleiche Abruf noch einmal:
Code: 
Dec 21 21:18:56 h123456 pop3d:
Dec 21 21:18:56 h123456 pop3d: IMAP connect from @ [84.137.251.25]IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=testaccount, ip=[84.137.251.25]
Dec 21 21:18:56 h123456 pop3d: LOGIN, user=agr, ip=[84.137.251.25]
Dec 21 21:18:56 h123456 pop3d:
Dec 21 21:18:59 h123456 pop3d:
Dec 21 21:18:59 h123456 pop3d: IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=agr, ip=[84.137.251.25]
Dec 21 21:18:59 h123456 pop3d: IMAP connect from @ [84.137.251.25]IMAP connect from @ [84.137.251.25]IMAP connect from @ [84.137.251.25]INFO: LOGIN, user=webmaster, ip=[84.137.251.25]
Dec 21 21:18:59 h123456 pop3d: LOGIN, user=testaccount, ip=[84.137.251.25]
Dec 21 21:18:59 h123456 pop3d: LOGIN, user=postmaster, ip=[84.137.251.25]
Dec 21 21:18:59 h123456 pop3d:
Die mail.err sagt Wenig aus:
Code: 
Dec 21 21:17:24 h942289 last message repeated 2 times
Mir sieht das logfile arg verunstaltet aus. Der Server scheint sich irgendwie zu verschlucken, wenn mehrere Anfragen in zu kurzer Zeit kommen.

Ausserdem ist mir aufgefallen, dass eine Menge mehr mail-relevante jobs auf dem Server laufen, als vor dem Server-upgrade

Code: 
11330 ?        S<s    0:00 /sbin/udevd --daemon
11542 ?        Ss     0:00 /usr/bin/dbus-daemon --system
11618 ?        Ss     0:00 /usr/sbin/hald --daemon=yes --retain-privileges
11896 ?        Ss     0:00 /sbin/syslogd -a /var/lib/named/dev/log
11909 ?        S      0:00 /usr/lib/courier-imap/couriertcpd -address=0 -stderrlogger=/usr/sbin/courierlogger -stderrlogge
11911 ?        S      0:00 /usr/sbin/courierlogger imapd
11921 ?        S      0:00 /usr/lib/courier-imap/couriertcpd -address=0 -stderrlogger=/usr/sbin/courierlogger -stderrlogge
11923 ?        S      0:00 /usr/sbin/courierlogger imapd-ssl
11930 ?        S      0:00 /usr/lib/courier-imap/couriertcpd -address=0 -stderrlogger=/usr/sbin/courierlogger -stderrlogge
11932 ?        S      0:00 /usr/sbin/courierlogger pop3d
11940 ?        S      0:00 /usr/lib/courier-imap/couriertcpd -address=0 -stderrlogger=/usr/sbin/courierlogger -stderrlogge
11942 ?        S      0:00 /usr/sbin/courierlogger pop3d-ssl
11950 ?        Ss     0:00 /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid
11956 ?        Ss     0:00 /usr/sbin/xinetd
12007 ?        Ssl    0:00 /usr/sbin/named -t /var/lib/named -u named
12021 ?        S      0:00 /bin/sh /usr/bin/mysqld_safe --user=mysql --pid-file=/var/lib/mysql/mysqld.pid --socket=/var/li
12056 ?        Sl     0:16 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql
12070 ?        S      0:00 qmail-send
12073 ?        S      0:00 splogger qmail
12074 ?        S      0:00 qmail-lspawn ./Maildir/
12075 ?        S      0:00 qmail-rspawn
12076 ?        S      0:00 qmail-clean
12090 ?        Ss     0:03 /usr/sbin/spamd --username=popuser --daemonize --nouser-config --helper-home-dir=/var/qmail --m
12091 ?        S      0:01 spamd child
12153 ?        Ss     0:00 /usr/local/psa/admin/bin/httpsd
12157 ?        S      0:25 /usr/local/psa/admin/bin/httpsd
12187 ?        Ss     0:00 /usr/sbin/cron
22223 ?        S      0:24 /usr/local/psa/admin/bin/httpsd
23588 ?        Ss     0:01 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
23589 ?        S      0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
24443 ?        S      0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
24444 ?        S      0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
32714 ?        S      0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
32715 ?        S      0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
Macht das eigentlich Sinn?

Weiss jemand Rat, warum das System scheinbar nicht mehr damit klar kommt, wenn mehrere Mailkonten in kurzer Folge abgerufen werden?

Ich bin für jeden Hinweis dankbar.

Viele Grüße
Matthias
 
Ich rate mal so ins Blaue hinein: Deinem vServer gehen beim (nahezu) gleichzeitigen Zugriff die Ressourcen aus und daher werden die dabei erzeugten Kind-Prozesse vom Kernel beendet (ohne, dass sie noch eine Fehlermeldung an den syslogd schicken könnten)...
Schau mal mit
Code: 
cat /proc/user_beancounters
nach, ob in der letzten Spalte Werte stehen, die nicht "0" sind.

Viele Grüße,
LinuxAdmin
 
Danke für die schnelle Antwort.
Nicht schlecht geraten schätze ich, auch wenn ich aus der Ausgabe von user_beancounters noch keine konkrete Handlung ableiten kann:
Code: 
Version: 2.5                                                                   
       uid  resource           held    maxheld    barrier      limit    failcnt
    123456: kmemsize        3574701    3582885    8512433    9823665          0
            lockedpages           0          0       3800       4096          0
            privvmpages       80175      80275     138256     202568      14078
            shmpages          13976      13976     131072     131072          0
            dummy                 0          0          0          0          0
            numproc              49         49        232        232          0
            physpages         33433      33437          0 2147483647          0
            vmguarpages           0          0      66400 2147483647          0
            oomguarpages      33457      33461      66400 2147483647          0
            numtcpsock           17         17        500        500          0
            numflock              9          9        200        232          0
            numpty                1          1         64         64          0
            numsiginfo            0          1        512        512          0
            tcpsndbuf        152048     152048    4683256    6102456          0
            tcprcvbuf        278528     278528    4683256    6102456          0
            othersockbuf      37568      37568    1503232    4063232          0
            dgramrcvbuf           0          0     240000     262144          0
            numothersock         27         27        382        382          0
            dcachesize            0          0    2194304    2317184          0
            numfile            1956       1956       5432       5432          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            54         54        128        128          0

Scheinbar stimmt was bei privvmpages nicht.
Kann ich das irgendwie ändern?

Wie gesagt: der Rechner lief mit den gleichen Domains und Anzahlen von Mail-Konten unter Suse 9.3 fast zwei Jahre problemlos - wenn es denn der gleiche Rechner nach dem Update geblieben ist.

Viele Grüße
Matthias
 
Habe das Problem scheinbar gelöst

Nachdem mir auch der Strato Support nicht weiterhelfen konnte, habe ich beim Schmökern in den Config-Files noch eine Einstellung gefunden, die mir (scheinbar) tatsächlich geholfen hat. Eigentlich trivial - wenns man weiss.

Unter
Code: 
/etc/courier-imap


habe ich in den Config-Files imapd und pop3d die Einstellung für die Maximalzahl von gleichzeitigen Mailabrufen von einer IP-Adresse gefunden.

Code: 
##NAME: MAXPERIP:0
#
#  Maximum number of connections to accept from the same IP address
#
# DEFAULT SETTING from /etc/courier-imap/imapd.dist:
#
#MAXPERIP=4
#

MAXPERIP=10

Den Default-Wert von 4 habe ich auf 10 erhöht.
Das selbe auch in imapd.dist, pop3d und pop3d.dist durchgeführt. Dann den Maildaemon neu gestartet

Code: 
/etc/init.d/courier-imap restart

Nun ist die fast gleichzeitige Abfrage mit Thunderbird möglich.
Die Logfiles sehen aber immer noch korrupt aus. So ganz sauber scheint also immer noch etwas nicht zu sein, aber mir reicht die Lösung erst mal.

Viele Grüße
Matthias
 
You must log in or register to reply here.
Back
Top