Zarafa & Fetchmail - Serverprozess stürzt ab

[smueff]

Hi Community,

ich lese hier sehr viel, nun habe ich endlich mal eine Frage an euch =)

Ich habe meinem selbstständigen Freund eine DS-212j besorgt und versuche ihm darauf die Zarafa Community Edition zum laufen zu kriegen (Er benutzt momentan noch Outlook/iPhone mit einem POP/IMAP Mailserver, da kommt Zarafa/z-Push als Ablöse genau richtig). Durch das bereitgestellte SPK 0.3.3 (vielen Dank Julian Dohle! =)) ist die Einrichtung supereinfach( ich komme eig. aus der Debian Welt und richte hin und wieder mal einen Zarafa Server ein).

Soweit lief auch alles (fetchmail hatte ich noch nicht getestet), ich hatte alles vorbereitet für den Umstieg vom Outlook/IMAP Account, den mein Kumpel bisher hatte und wollte nun die Mails via Fetchmail (konfiguriert in der Fetchmail GUI der Synology im "Zarafa Administrator") abholen und dem (einen) angelegten Zarafa User zuleiten. Die Konfig via GUI funktioniert, in der /etc/fetchmailrc gibt es danach Inhalt.

Jetzt kommt das Problem: Mein Zarafa-Server (genauer der zarafa-server Prozess) läuft so lange, bis der Fetchmail gestartet wird. 645 Mails will er abholen aus dem POP3-Postfach beim Provider, ganze sechs Stück hat er bereits abholen (flushen) können. Danach erhalte ich im /var/log/fetchmail.log immer diesselbe Meldung (ein Auszug):

fetchmail: MDA returned nonzero status 75
fetchmail:  not flushed
fetchmail: reading message anja@gdtech.de@mail.gdtech.de:13 of 638 (225092 octets) (log message incomplete)
fetchmail: MDA returned nonzero status 75
fetchmail:  not flushed
fetchmail: reading message anja@gdtech.de@mail.gdtech.de:14 of 638 (1742 octets) (log message incomplete)
fetchmail: MDA returned nonzero status 75
fetchmail:  not flushed
fetchmail: reading message anja@gdtech.de@mail.gdtech.de:15 of 638 (87268 octets) (log message incomplete)
fetchmail: MDA returned nonzero status 75
fetchmail:  not flushed
fetchmail: reading message anja@gdtech.de@mail.gdtech.de:16 of 638 (7487 octets) (log message incomplete)

Solange bis ich den Fetchmail wieder stoppe (bzw. /var/packages/Zarafa/scripts/start-stop-status stop ausführe, das stoppt Zarafa & Fetchmail).

Interessant ist seitens Zarafa, dass nahezu zeitgleich der zarafa-server Prozess durch einen Fehler beendet wird:

Tue Feb 26 20:59:25 2013: Caught SIGSEGV (11), traceback:
Tue Feb 26 20:59:25 2013: 0x000000003c561c /usr/local/zarafa/bin/zarafa-server [0x3c561c]
Tue Feb 26 20:59:25 2013: When reporting this traceback, please include Linux distribution name, system architecture and Zarafa version.

Ich habe das log_level in der /etc/zarafa/server.cfg mal auf Debug gestellt, also 6. Mehr als diese Meldung ist dem Log also leider nicht zu "entloggen" (haha...) =(

Bzgl. Fetchmail habe ich mich schon durch dieses Forum gesucht und ein wenig mit den Berechtigungen gespielt (wie hier: http://www.synology-forum.de/archive/index.html/t-28808.html?). Ich habe den User Fetchmail im DSM angelegt und den Besitzer von /etc/fetchmailrc (bzw. /var/packages/Zarafa/etc/fetchmailrc) und /var/log/fetchmail auf fetchmail.users umgestellt, ebenso das Zarafa-Startskript so angepasst, dass dieses als fetchmail ausgeführt wird. Die /var/log/zarafa/dagent.log Berechtigung testweise auf 666 gestellt. Danach stürtze der zarafa-server nicht mehr ab, allerdings wurde fetchmail auch nicht gestartet, evtl. ein Konfigurationsfehler aber das Ganze ging mir auch nicht so wirklich in die richtige Richtung...Ich habe dann wieder alles zurückgestellt (chown wieder zurück auf root, dagent.log auf 600 usw). Nun ist alles wieder im Ausgangszustand.

Da ich zu dem Zarafa server.log-Fehler nichts gefunden hab wollte ich mal Fragen, ob jemand eine vage Vermutung hat, woran es liegen könnte, dass fetchmail mir diese Meldungen ausspuckt und den zarafa-server dadurch beendet (so scheint es zumindest).

Ich weiß, die Alternative könnte sein, unabhängig der Zarafa Administrations GUI die /etc/fetchmailrc so anzupassen, dass empfangene Mails nicht direkt an den dagent übergeben werden, sondern dem postfix zuzuspielen, um die Mail weiterzugeben (an den dagent...). Die direkte dagent-Methode ist natürlich am elegantesten und ich kann die GUI weiter nutzen. Das wär mir am liebsten =)

Ich weiß auch, das grenzt fast an einen TLDR-Post, wer sich trotzdem die Zeit und das Hirnschmalz genommen hat es zu lesen: Vielen Dank!

Es grüßt ein verzweifelter Synology Admin

 

[bon_go]

Hast Du inzwischen eine Lösung für das Problem gefunden?

 

[oj69]

Probiers mal mit den aktuellen Versionen. Ansonsten würde ich vermuten, dass Du ein Speicherproblem mit fetchmail/Zarafa hast. Die DS212j ist ja nicht nicht gerade übermässig üppig an Speicher ausgestattet ...

 

[bon_go]

Hat sich bei mir inzwischen erledigt.

Das Problem war die separate Ablage und standardmäßige Komprimierung der Attachments. Die Anlagen können nicht komprimiert abgelegt werden. Der Zarafa Server stürzt dann beim Empfang einer E-Mail mit Anhang ab. Wenn die Komprimierung deaktiviert wird geht's.

Anbei meine Installationshilfe für Zarafa 7.1.7 auf einer Synology mit wenigstens 512 MB Ram:

# startet die mysql shell, die Passwortabfrage mit Enter bestätigen                      
/usr/syno/mysql/bin/mysql -u root -p                          

# setzt das Passwort für alle 3 root Zugänge
UPDATE mysql.user SET Password=PASSWORD("<neues Passwort>") WHERE User="root";

# setzt neue mysql Startparameter für Zarafa
sed -i 's/^MYSQL_ARGS=.*$/MYSQL_ARG="--innodb_buffer_pool_size=200M --innodb_log_file_size=50M --innodb_log_buffer_size=32M --max_allowed_packet=16M --max_connections=100"/' /usr/syno/etc/rc.d/S21mysql.sh

# beendet den mysql Dienst                                            
/usr/syno/etc/rc.d/S21mysql.sh stop         

# löscht die beiden inno db Logfiles
rm /volume1/@database/mysql/ib_logfile*     

# startet den mysql Dienst
/usr/syno/etc/rc.d/S21mysql.sh start        

# ab hier die Zarafa Installation über den DSM durchführen, 
# dabei das eben gesetzte mysql Passwort eingeben und 
# die Installation fertig stellen, Zarafa muss nach der Installation 
# einmal starten, dabei werden div. config Dateien und die mysql 
# Tabellen angelegt anschließend über den DSM Paketmanager Zarafa stoppen

# legt ein Verzeichnic für die Ablage der E-Mail Anhänge an
mkdir /volume1/attachments                

# setzt die Zarafa Option der Ablage der E-Mail Anhänge 
sed -i 's/^attachment_storage.*$/attachment_storage = files/' /etc/zarafa/server.cfg
                                           
# setzt die Zarafa Option des Verzeichnisses der Ablage der E-Mail Anhänge                                            
sed -i 's|^attachment_path.*$|attachment_path = /volume1/attachments/ |' /etc/zarafa/server.cfg
                                           
# behebt einen Bug: deaktiviert die Komprimierung der Dateiablage der E-Mail Anhänge                                            
sed -i 's/^attachment_compression.*$/attachment_compression = 0/' /etc/zarafa/server.cfg
                                           
# behebt einen Bug im Zarafa, Postfach wäre sonst niederländisch :)                                           
sed -i 's/"nl_NL.utf8"/"de_DE.utf8"/' /etc/sysconfig/zarafa
                                           
# startet den Zarafa Server einmalig mit einer speziellen startoption                                           
/usr/local/zarafa/bin/zarafa-server -c /etc/zarafa/server.cfg --ignore-attachment-storage-conflict
                                           
# beendet den Zarafa Server wieder                                           
/volume1/@appstore/Zarafa/etc/init.d/zarafa-server stop
      
# kompletter Neustart
reboot

Habe Zarafa auf einer DS212+, einer DS214 sowie testweise auf XPE laufen.

 

[bon_go]

Etwas OT - aber da habe ich gleich noch eine Gegenfrage an oj69: wie schnell ist deine DS713+?

Ich teste schon einige Weile die Geschwindigkeit verschiedener Synologys und anderen Plattformen. Daten über die Geschwindigkeit der verwendeten CPU bzw. echte Benchmarks gibt's nirgends. Ich habe mich auf einen gemeinsamen Nenner und einen praktischen Test beschränkt: Kompilieren des Zarafa 7.1.7 unter akt. Debian 7 mit GCC 4.8.1 auf verschiedenen Plattformen. Als Datenträger kommt dabei immer eine SSD Samsung 840 EVO mit 120 GB zum Einsatz.

Das habe ich auf folgenden Plattformen durchgeführt: [br]
- DS212+: Marvell Armada 300 @1GHz 512 MB RAM DDR3 @16bit
- DS214: Marvel Armada XP 2x @1 GHz 512 MB RAM DDR3 @16 bit
- Cubieboard 1 Allwinner A10 @1GHz 1 GB RAM
- Cubietruck Allwinner A20 2x @1GHz 2 GB RAM
- AMD PC mit A8-5600K, 'Quadcore', 4 GB RAM

Demnächst kommt noch:
- DS213+
- DS509+
- Raspberry Pi - leider nur mit einer SDCard
- weitere PC Plattformen
- Handys soweit ich Debian dort zum laufen kriege

Mich würde wirklich interessieren was bei einer DS713+ rauskommt.

Ich habe dafür auch eine Art Ablaufskript gebastelt. Die Synos werden davon nicht berührt. Es werden alle Dienste gestoppt, das passiert alles per SSH und es wird nur etwas Platz auf einem Volume benötigt. Die grundlegende Synology Installation wird nicht geändert. Bei Interesse mal melden ...

Warum Zarafa kompilieren? Das ist ein praktischer Test und der ist irgendwie vergleichbar, SSD vorausgesetzt. Es geht mir vorrangig um die mögliche Rechenleistung. Bei der Nutzung von Zarafa ist das der Flaschenhals. Das Thema Menge des RAM und dessen Nutzung habe ich dabei auch erstmal unter den Tisch gekehrt. Üblicherweise wird bei solchen Tests ein Linux Kernel kompiliert - Stichwort kcbench unter x64. Das habe ich nicht sauber auf allen ARM Plattformen hinbekommen, der make Prozess schmiert hier und da ab.

 

[oj69]

Die DS 713+ ist schon ziemlich fix im Vergleich zur 213+ (die ich vorher hatte). In konkreten Zahlen kann ich das natürlich nicht ausdrücken. Ich denke aber mal, es liegt an 2 Faktoren: a) vollwwertige CPU und b) RAM von 1 GB. Insbesondere beim Zarafa-Kalender über das Webinterface ist das spürbar. Und: das Zarafa-Paket für Synology ist ja noch im Beta-Stadium. Da ist sicherlich noch einiges Pontential zu heben