[Postfixbuch-users] Postfix Probleme auf VServer

Sandy Drobic postfixbuch-users at japantest.homelinux.com
Mo Nov 6 19:11:07 CET 2006


Stefan Marx wrote:
> ..
>>> Hat schon mal jemand ein ähnliches Problem gehabt bzw. behoben? Oder
>>> eine Idee, wonach ich genau suchen muß? Der Vserver liegt auf einem
>>> GFS-Filesystem das über FC-SAN angebunden ist, kann es damit
>>> zusammenhängen?
>> Durchaus möglich, denn Postfix verwendet die Inode, um die Queue-ID zu 
>> bestimmen. Deshalb kann es trickreich sein, wenn in einem übergreifenden 
>> System Postfix dort sein Spoolverzeichnis hat.
>>
>> Eine andere Schwierigkeit könnte sein, wenn GFS ein anderes Lock-Verfahren 
>> verwendet als Postfix. Postfix sieht sein Spoolverzeichnis als lokal und 
>> exklusiv. Ich habe leider keine Erfahrungen mit GFS.
>>
>> Wie sieht es denn mit offenen Dateien, Prozesen und den ulimits aus?
> 
> 
> Vserver:
> 
> ulimit -a
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> max nice                        (-e) 20
> file size               (blocks, -f) unlimited
> pending signals                 (-i) unlimited
> max locked memory       (kbytes, -l) unlimited
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) unlimited
> max rt priority                 (-r) unlimited
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) unlimited
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited
> 
> Hardware:
> 
> ulimit -a
> core file size        (blocks, -c) 0
> data seg size         (kbytes, -d) unlimited
> file size             (blocks, -f) unlimited
> max locked memory     (kbytes, -l) unlimited
> max memory size       (kbytes, -m) unlimited
> open files                    (-n) 1024
> pipe size          (512 bytes, -p) 8
> stack size            (kbytes, -s) 8192
> cpu time             (seconds, -t) unlimited
> max user processes            (-u) unlimited
> virtual memory        (kbytes, -v) unlimited
> 
> Sieht eigentlich relativ gleich aus. Der Vserver Host hat einen
> 2.6.15-27-server Kernel von Ubuntu mit Vserver-Patch und als
> Betriebssystem Ubuntu Dapper Drake, der Vserver ist ein Debian Sarge und
> Hardware hat einen selbstkompilierten 2.6.14.2 und läuft ansonsten auf
> einem Standard Debian Sarge.

Das sieht eigentlich recht gut aus, wenn nicht viele Files gleichzeitig 
offen sind, sollte das auch daran nicht scheitern. Bleibt noch der 
Locking-Mechanismus von GFS und Postfix, ob dieser kompatibel ist.

> Was die Frage mit den Inodes angeht... Da muß ich passen, ein Vserver
> sieht folgendes: /dev/hdv1 on / type ufs (defaults) . Drunter liegt ein
> LVM-Volume: /dev/mapper/vg1-vservers on /m1 type gfs (rw). Der
> Pfad /m1/vservers/mailrouter/ wird in dem Vserver zu /. 

Hier ein kurzer Auszug zu den Anforderungen für das Dateisystem der Mailqueue:

Gory details: the Postfix mail queue requires that (1) the file system can 
rename a file to a near-by directory without changing the file's inode 
number, and that (2) mail is safely stored after fsync() (of that file, 
not its parent directory) returns successfully, even when that file is 
renamed to a near-by directory at some later point in time. Maildir 
delivery also requires that (3) a file can be hard linked between 
different near-by directories. Mailbox delivery introduces no additional 
requirements beyond what is already needed for Postfix queues.


Checke das doch mal gegen die Beschreibung von GFS, wie dort fsync und die 
Zuordnung von File/Inode gehandhabt wird.

Sandy
-- 
Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com




Mehr Informationen über die Mailingliste Postfixbuch-users