Owserver tot und massig Einträge im Syslog

[lio123]

nachdem nun all runter ist, scheint die Ursache immer noch nicht behoben zu sein.
Kann man erstmal Exim nicht stoppen?

GRüße,
Lio

[lio123]

so iss doch gut, oder?

Makki, hast Du / Ihr was gemacht?

Memory cached ist noch a weng hoch, oder?

Grüße,
Lio

[makki]

Nein, ich habe seit gestern - wie berichtet - nichts gemacht.
Die Files im Mail-Sppol bitte hübsch einzeln löschen, Häppchenweise (1V*, 1U* usw) nicht an den Verzeichnis(Rechten) drehen, das hat mehr Fehlerpotential..
Und danach einfach (exim) durchstarten.

Cached ist ok, alles was "free" ist, wird automatisch für Cache verwendet. Der verfügbare Speicher ist also eigentlich "Free"+"Cached", das sieht gut aus.

Makki

[lio123]

ah, ok danke, dann waren das wohl die Nachwehen.
Ich habe seit heute morgen immer mit Strg+A und Entfernen gelöscht.

Wie sieht es mit der Verzeichnisstruktur des EXIM aus?
DA gibt es noch /var/spool/exim4

/input mit Massig Dateien mit Inhalt (wohl der Verursacher)z.B Diese Datei wurde heute Mittag 14:43 Uhr erzeugt, Innendrind steht der 14.01.!.:

X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
Message-Id: <E1W352L-000278-Mm@wiregate534>
Date: Tue, 14 Jan 2014 15:32:13 +0100

Step 1 - Daten holen 
Step 2 - Reg Exp 1 Datensatz zusammensetzen 
Zaehler Haushalt: 
Step 3 - Datensatz auswerten 
010800FF     Obis
63018201621E52FF56000528F603 contains hex 
000528F603 hex 
8657.0499<<<<---- Wert
COUNTER
WP_Zaehler_Verbrauch obisname 
8657.0499 value 
WP_Zaehler_Verbrauch_5.rrd
WP_Zaehler_Verbrauch obisname 
8657.0499 value 
WP_Zaehler_Verbrauch_15.rrd
WP_Zaehler_Verbrauch obisname 
8657.0499 value 
WP_Zaehler_Verbrauch_60.rrd
WP_Zaehler_Verbrauch obisname 
8657.0499 value 
WP_Zaehler_Verbrauch_1440.rrd
GA:14/7/53 Wert:8657.0499 DPT:14
0F0700FF     Obis
0101621B52FF55000004D2 contains hex 
000004D2 hex 
12.34<<<<---- Wert
GAUGE
WP_Zaehler_Leistung_Ges obisname 
12.34 value 
WP_Zaehler_Leistung_Ges.rrd
GA:14/7/52 Wert:12.34 DPT:14
010801FF     Obis
0101621E52FF560002A2C025 contains hex 
0002A2C025 hex 
4422.0453<<<<---- Wert
COUNTER
WP_Zaehler_Leistung_Tarif1 obisname 
4422.0453 value 
WP_Zaehler_Leistung_Tarif1_5.rrd
WP_Zaehler_Leistung_Tarif1 obisname 
4422.0453 value 
WP_Zaehler_Leistung_Tarif1_15.rrd
WP_Zaehler_Leistung_Tarif1 obisname 
4422.0453 value 
WP_Zaehler_Leistung_Tarif1_60.rrd
WP_Zaehler_Leistung_Tarif1 obisname 
4422.0453 value 
WP_Zaehler_Leistung_Tarif1_1440.rrd
GA:14/7/54 Wert:4422.0453 DPT:14
010802FF     Obis
0101621E52FF5600028635DE contains hex 
00028635DE hex 
4235.0046<<<<---- Wert
COUNTER
WP_Zaehler_Leistung_Tarif2 obisname 
4235.0046 value 
WP_Zaehler_Leistung_Tarif2_5.rrd
WP_Zaehler_Leistung_Tarif2 obisname 
4235.0046 value 
WP_Zaehler_Leistung_Tarif2_15.rrd
WP_Zaehler_Leistung_Tarif2 obisname 
4235.0046 value 
WP_Zaehler_Leistung_Tarif2_60.rrd
WP_Zaehler_Leistung_Tarif2 obisname 
4235.0046 value 
WP_Zaehler_Leistung_Tarif2_1440.rrd
GA:14/7/55 Wert:4235.0046 DPT:14

dann gibt es noch
/db mit harmlosen Inhalt.






Mein Vorschlag wäre die Dateien zumindest im Input-Ordner zu löschen.
Danach würde ich EIN- SML-Skript, mit dem ergänzten CRONTAB wieder in betrieb nehmen. Ich weiss ja wo ich nun überprüfen muss.

Wenn das geht, dann das 2te SML-Skript, danach die restlichen Plugins.

Spricht was dagegen?

Danke und Grüße,
Lio

[makki]

Lass das erstmal "abflauen", da kommen vermutlich nur noch ein paar nach..
Also genau so, files kann man dort einfach löschen, das Verzeichnis muss aber dableiben!

Wie von JuMi schon geschrieben sollte das dazu führen, das keine neuen eMails pro Aufruf mehr erzeugt werden.
Kann man natürlich auch global abschalten:

MAILTO=""

in die crontab

Makki

[lio123]

So.
Das war jetzt eine 3 tage Löschaktion.
Heute spukte der EXIM noch ein paar leere Files in sein input/mslog Verzeichnis.
Das SML-Plugin habe ich gerade in Betrieb genommen.
Wenn ich Cron im Webmin ausführe bekomme ich mit der angehängten Syntax keine Ausgabe angezeigt. Ich nehme an, das soll so sein, da auch keine mail abgesetzt wird??!!! Zuvor ging das.

Der inodes ist auch in Ordnung?


Danke und Gruß,
Lio

[makki]

Naja das merkste ja, wenn keine Mails im spool mehr auflaufen passt es..

Inodes ist gut, das waren sicherlich primär die cron-mails.

Makki

[lio123]

hmm.

Das smlWP.pl wird nur ausgeführt, wenn ich das mit "perl smlWP.pl" anstosse und zwar genau einmal.

Den Eintrag im CRON habe ich genauso hergestellt wie im Anhang.

Es scheint da was nicht zu laufen.

So wie ich das deute, war es so, dass CRON das sh-skript aufrief, und dieses dann das PERL.Skript startete, bzw killte.

GRuß,
Lio

[lio123]

Denk, ich habe den Fehler gefunden. Es lag an den Berechtigungen.
Habe dieses >/dev/null 2>&1 entfernt und CRON ausführen lassen.
Dann kam die Meldung, dass der Zugriff verweigert wurde.

GRüße,
Lio