qmail stirbt ohne Hinweise

  • Thread starter Thread starter fran-k
  • Start date Start date
F

fran-k

Guest
Hallo!

Ich habe auf meinem Server ein größeres Problem mit qmail.
Es stürzt seit Beginn unregelmäßig (zwischen 2 mal am Tag und
14 Tagen) und nicht reproduzierbar ab.

In der /var/log/ (alle Files und besonders syslog) sind keinerlei Informationen warum, oder wann es passiert ist, enthalten . Es sind nur Einträge vorhanden, über Mails die zugestellt wurden, auch in /var/qmail/ war nichts zu finden.

Das ganze läuft unter Debian Sarge mit Plesk 7.5.4 auf einem P4 3Ghz und
1 Gb RAM, also Ressourcen möchte ich fast ausschliessen.

Hat jemand eine Idee, wo ich ansetzen kann?!

Danke euch!

Gruß, Frank
 
Hallo!
Habe irgendwie dunkel in Errinnerung, das es öfter zu Problemen mit der Kombination Plesk & qmail kommt. Eventuell kann Huschi noch etwas dazu sagen. Hast du mal die Forensuche strapaziert?

mfG
Thorsten
 
Ja, ich hab die Forensuche benutzt aber ohne Erfolg.

Bin auch mal gespannt, ob und was Huschi sagt ;)

Gruß, Frank
 
Deaktivier mal den Watchdog in Plesk und beobachte das Problem weiter.

Bei mir hat es bisher geholfen.

Soll lt. FAQ SW-Soft noch Probleme geben.

cu
michael
 
Ok, ich habe den Watchdog mal deaktiviert und werde das beobachten.
Vielleicht klappt es ja. Wäre echt Sahne!

Danke Dir für den Tip.

Gruß, Frank
 
Wenn alle nach mir rufen, muß ich wohl auch kommen, wa?

fran-k said:
Es stürzt seit Beginn unregelmäßig (zwischen 2 mal am Tag und 14 Tagen) und nicht reproduzierbar ab.
Definier 'abstürzen'. Wie stellst Du es fest, welche Diagnose-Tools verwendest Du?
Hast Du diesen Artikel schon gelesen: Plesk-Watchdoc sagt: "qmail down"

huschi.
 
Huschi said:
Wenn alle nach mir rufen, muß ich wohl auch kommen, wa?
Das finde ich prima ;)

Huschi said:
Definier 'abstürzen'. Wie stellst Du es fest, welche Diagnose-Tools verwendest Du?
Einmal stelle ich es auf Zuruf fest. Leute, dennen ich über ICQ sage, dass ich grade was an sie verschicke, fragen nach, wo es bleibt.
Und dann schaue ich immer wieder in Plesk rein, in die Dienstübersicht und sehe qmail dann entsprechend auf 'gestoppt' stehen. Starte ich es dann wieder, geht der mailversand.

Huschi said:
Hast Du diesen Artikel schon gelesen: Plesk-Watchdoc sagt: "qmail down"
Nein, noch nicht. Werde ich direkt aber in Angriff nehmen.

Danke Dir!

Gruß, Frank
 
fran-k said:
Und dann schaue ich immer wieder in Plesk rein,
Schau besser per "ps -aux |grep qmail" nach. mach evtl. einen restart in der Shell und beobachte die Mail-Queue mit /var/qmail/bin/qmail-qstats.

huschi.
 
Hallo Huschi,

danke Dir.
Ich werde das mal im Auge behalten.

Bisher ist qmail ganz ruhig und macht keine Probleme, seitdem ich Watchdog deaktiviert habe.

Gruß, Frank
 
So, das muß es dann wohl gewesen sein, denn bisher war qmail richtig brav un lieb.

Ich danke euch nochmal für die Hilfe!
Wirklich klasse hier!!

Gruß, Frank
 
xeomueller said:
indem du einen cronjob erzeugst:
Meinst Du diesen?
Code:
0,10,20,30,40,50 * * * * /etc/init.d/qmail reload >/dev/null 2>&1
Er reloaded die ganze qmail-Umgebung alle 10 Minuten.

PS: Wir haben nichts gegen Quellenangaben, aber Lösungen wollen wir möglichst vollständig hier lesen können.

huschi.
 
Mögliche Lösung

Hi,

ich will mal vorsichtig sagen, dass ich eventuell eine ->echte Lösung<- für diese beiden Probleme habe, wer das mal getestet hat, bitte Feedback an mich.
Ich habe das mehr oder weniger zufällig aus einer anderen Ecke des SWsoft Plesk Support (USA).



2 problems related to mail in plesk 7.5.4 on debian: watchdog module and inetd <-> qmail

problem one: the watchdog module
setup:
- Debian 3.1 (probaly applies to 3.0 too, if setup was done manual)
- Plesk 7.5.4
- Watchdog Module

observed problem:
qmail gets killed by watchdog module and a race condition leads to service outage

problem 2: qmail dies simply on it's own
setup:
- Debian 3.1 (probaly applies to 3.0 too, if setup was done manual)
- usage of classic inetd for qmail due to debian defaults
- Plesk 7.5.4

observed problem:
qmail just dies on (highee volume/low resource) systems, no traces found


solution suggested for problem 1:
- find out which scripts are called by the watchdog module for qmail checks
- disable all watchdog module settings for qmail
- delete the scripts used for qmail checks (not the templates)
- apply patch to watchdog module template
- setup new watchdog job for qmail
- check that the new generated script has the updates from the patched template
(only if that fails-> get the source of the plesk installation package, remove the watchdog module completely using dpkg, reinstall the watchdog module, appy patch, setup qmail monitoring, check script for updates from patch)

- > if qmail is started from inetd (not xinetd) continue with next


solution suggested for problem 2:
- replace inetd with xinetd

-> the qmail inetd IPC does not work properly in this setup, xinetd removes the blocker and leads to a defined state under all conditions

Und hier der Patch für das watchdog module template:
<code>
--- monitrc.tpl.orig 2006-01-26 15:22:34.000000000 +0100
+++ monitrc.tpl 2006-01-26 16:21:51.769476416 +0100
@@ -62,18 +62,27 @@
mode <apache::mode>

# Qmail
-check host qmail with address localhost
- start = "<qmail::start>"
- stop = "<qmail::stop>"
- if failed host localhost port 25 protocol smtp with timeout <qmail::connection_timeout> seconds then <qmail::action>
- [<rem qmail::timeout>]if <qmail::timeout::restarts> restarts within <qmail::timeout::cycles> cycles then timeout
- every <qmail::every cycles> cycles
- [<rem qmail::alert::nonwork>]alert <qmail::alert::nonwork::to> { connection } [<qmail::alert::nonwork::mail-format>]
- [<rem qmail::alert::exec>]alert <qmail::alert::exec::to> { exec } [<qmail::alert::exec::mail-format>]
- [<rem qmail::alert::timeout>]alert <qmail::alert::timeout::to> { timeout } [<qmail::alert::timeout::mail-format>]
- alert <default email to> {invalid}
- mode <qmail::mode>
-
+check process qmail
+ with pidfile "/var/run/qmail.pid"
+ start = "<qmail::start>"
+ stop = "<qmail::stop>"
+ [<rem qmail::timeout>]if <qmail::timeout::restarts> restarts within <qmail::timeout::cycles> cycles then timeout
+ every <qmail::every cycles> cycles
+ [<rem qmail::alert::exec>]alert <qmail::alert::exec::to> { exec } [<qmail::alert::exec::mail-format>]
+ [<rem qmail::alert::timeout>]alert <qmail::alert::timeout::to> { timeout } [<qmail::alert::timeout::mail-format>]
+ alert <default email to> {invalid}
+ mode <qmail::mode>
+
+# Qmail-smtpd
+check qmail_smtpd with address localhost
+ if failed host localhost port 25 protocol smtp with timeout <qmail::connection_timeout> seconds then alert
+ [<rem qmail::timeout>]if <qmail::timeout::restarts> restarts within <qmail::timeout::cycles> cycles then timeout
+ every <qmail::every cycles> cycles
+ [<rem qmail::alert::nonwork>]alert <qmail::alert::nonwork::to> { connection } [<qmail::alert::nonwork::mail-format>]
+ [<rem qmail::alert::timeout>]alert <qmail::alert::timeout::to> { timeout } [<qmail::alert::timeout::mail-format>]
+ alert <default email to> {invalid}
+ mode <qmail::mode>
+
# Courier-IMAP
check process courier-imap
with pidfile "/var/run/imapd.pid"
</code>

alles zwischen den code Tags in eine Datei (patch.diff) speichern und im Ordner anwenden, in dem die Datei monitrc.tpl, also das Templatefile des Monitoring Skripts, liegt:
cd /opt/psa/....... (habe gerade kein plesk da zum gucken, "find / -name 'monitrc.tpl'" sollte aber helfen)
patch < /patch.diff -p0


Ich denke das SWsoft Debian irgendwie nicht mag, so sehr wie die das schleifen lassen, das wird bestimmt noch ewig dauern, bis da ein Upate für kommt.

Gruß MeMeD
 
Last edited by a moderator:
Back
Top