Owserver tot und massig Einträge im Syslog

[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

[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

[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]

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]

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]

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]

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]

so iss doch gut, oder?

Makki, hast Du / Ihr was gemacht?

Memory cached ist noch a weng hoch, oder?

Grüße,
Lio

[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]

hier mal:

/var/spool/exim4/msglog$ ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 init [2]     
    2 ?        S      0:00 [kthreadd]
    3 ?        S      0:04 [ksoftirqd/0]
    5 ?        S      0:01 [kworker/u:0]
    6 ?        S      0:00 [migration/0]
    7 ?        S      0:00 [watchdog/0]
    8 ?        S<     0:00 [cpuset]
    9 ?        S<     0:00 [khelper]
   10 ?        S      0:00 [kdevtmpfs]
   11 ?        S<     0:00 [netns]
   12 ?        S      0:00 [sync_supers]
   13 ?        S      0:00 [bdi-default]
   14 ?        S<     0:00 [kintegrityd]
   15 ?        S<     0:00 [kblockd]
   16 ?        S<     0:00 [ata_sff]
   17 ?        S      0:00 [khubd]
   18 ?        S<     0:00 [md]
   19 ?        S      0:00 [kworker/u:1]
   21 ?        S      0:00 [khungtaskd]
   22 ?        S      0:00 [kswapd0]
   23 ?        SN     0:00 [ksmd]
   24 ?        S      0:00 [fsnotify_mark]
   25 ?        S      0:00 [ecryptfs-kthrea]
   26 ?        S<     0:00 [crypto]
   34 ?        S<     0:00 [kthrotld]
   56 ?        S<     0:00 [deferwq]
   57 ?        S<     0:00 [devfreq_wq]
  702 ?        S<s    0:01 udevd --daemon
  712 ?        S      0:21 /usr/sbin/exim4 -q
 1047 tty1     Ss+    0:00 /bin/bash /usr/sbin/wiregate-tty.sh
 1500 ?        S      0:00 [flush-3:0]
 1722 ?        Ss     0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 104:105 -g -c /etc/ntp.conf.dhcp
 1725 ?        S      0:00 avahi-autoipd: [eth0] bound 169.254.122.107   
 1726 ?        Ss     0:00 avahi-autoipd: [eth0] callout dispatcher      
 1730 ?        Ss     0:00 dhclient3 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0
 1771 ?        Ss     0:00 /sbin/portmap
 1782 ?        Ss     0:00 /sbin/rpc.statd
 1944 ?        S      0:00 /usr/sbin/ser2net -c /etc/ser2net.conf -P /var/run/ser2net.pid
 1954 ?        S      0:02 /usr/sbin/snmpd -LSwd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid
 1960 ?        Ss     0:00 /usr/sbin/openvpn --writepid /var/run/openvpn.server.pid --daemon ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf
 1969 ?        Ss     0:03 /usr/sbin/openvpn --writepid /var/run/openvpn.wiregate-central.pid --daemon ovpn-wiregate-central --status /var/run/openvpn.wiregate-central.status 10 --cd /etc/openvpn --config /etc/openvpn/wiregate-central.conf
 1975 ?        Ss     0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
 2029 ?        S      0:01 /usr/sbin/ifplugd -i eth0 -b -q -f -u0 -d2 -w -I
 2050 ?        Ss     0:00 /usr/sbin/owhttpd -p 3001 -s localhost:4304 --pid_file /var/run/owhttpd.pid --nozero
 2054 ?        S      0:00 /usr/sbin/xplhub
 2056 ?        S      0:00 /usr/sbin/xplhub
 2061 ?        Ss     0:00 /usr/sbin/syslog-ng -p /var/run/syslog-ng.pid
 2065 ?        Ss     0:02 /usr/bin/eibd -e 1.1.253 -S -D -i -T -d -u --pid-file=/var/run/eibd.pid -c ipt:192.168.2.25
 2070 ?        Ss     0:00 /usr/sbin/nmbd -D
 2072 ?        Ss     0:00 /usr/sbin/smbd -D
 2078 ?        S      0:00 /usr/sbin/smbd -D
 2119 ?        Ss     0:00 /usr/sbin/atd
 2170 ?        SLs    0:00 /usr/sbin/watchdog
 2183 ?        Ss     0:00 /usr/sbin/cron
 2190 ?        Ss     0:00 /usr/bin/dbus-daemon --system
 2194 ?        Ss     0:00 /usr/sbin/inetd
 2209 ?        Ss     0:00 /usr/sbin/collectdmon -P /var/run/collectdmon.pid -- -C /etc/collectd/collectd.conf
 2212 ?        Sl     0:30 collectd -C /etc/collectd/collectd.conf -f
 2253 ?        Ss     0:01 /usr/bin/linknx -c/etc/linknx.xml -p /var/run/linknx.pid -d -w
 2270 ?        Ss     0:00 /usr/sbin/sshd
 2381 ?        S      0:02 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
 2534 ?        Ss     0:00 /usr/sbin/exim4 -bd -q30m
 2536 ?        S      6:24 /usr/sbin/exim4 -q
 2557 ?        S      0:12 /usr/bin/perl -w /usr/sbin/wiregated-ow.pl -p /var/run/wiregated-ow.pl.pid
 2568 ?        S      0:18 /usr/bin/perl -w /usr/sbin/wiregated.pl -p /var/run/wiregated.pl.pid
 2593 ?        Sl     0:01 /usr/sbin/monit -d 60 -c /etc/monit/monitrc -s /var/lib/monit/monit.state
 2600 ?        S      0:15 /bin/sh /usr/sbin/wiregated-uncached
 2645 ?        S      0:00 avahi-daemon: running [wiregate534.local]
 2646 ?        Ss     0:00 avahi-daemon: chroot helper
 2662 tty2     Ss+    0:00 /sbin/getty 38400 tty2
 2663 tty3     Ss+    0:00 /sbin/getty 38400 tty3
 2664 tty4     Ss+    0:00 /sbin/getty 38400 tty4
 2665 tty5     Ss+    0:00 /sbin/getty 38400 tty5
 2666 tty6     Ss+    0:00 /sbin/getty 38400 tty6
 2667 tty8     Ss+    0:00 /usr/bin/tail -f /var/log/syslog
 2668 tty9     Ss+    0:00 /usr/bin/vbusmonitor1time local:/tmp/eib
 2669 tty10    Ss+    0:00 /usr/bin/tail -f /var/log/user.log
 5124 ?        Ss     0:38 sshd: root@notty 
 5246 ?        Ss     1:30 /usr/lib/openssh/sftp-server
 6640 ?        S      0:00 /usr/lib/cgi-bin/r
 7985 ?        S      0:00 /usr/lib/cgi-bin/r
 8055 ?        Ss     0:00 sshd: root@notty 
 8152 ?        Ss     0:00 -bash
 8385 ?        Z      0:00 [watchdog] <defunct>
 8443 ?        R      0:00 /usr/sbin/exim4 -q

[lio123]

also ich habe jetzt mal da alles raus und auf das NAS übertragen.
Cron gelöscht, Skripte ins Nas, ALLE Plugins ebenfalls.

Danach habe ich diese Mail-Dateien gelöscht. Nach 3 Stunden bereche ich den Vorgang mal ab und nehme das WG vom Strom.

Danach würde ich gern einen Befehl zum Löschen dieser Maildateien auf dem WG absetzen, damit das ganze nicht über WinSCP laufen muss.


Würde das so gehen:

[B]cd /var/spool
 mv exim exim.old
 mkdir -p exim/input
 mkdir -p exim/msglog
 mkdir -p exim/db
 chown -R mail:mail exim
 /sbin/service exim restart[/B]

[makki]

Ok, Reboot erfolgte wohl lokal
Aber hat nicht gereicht, denn ein paar Minuten später wars wieder soweit:

Ehrlich:

-bash: fork: Cannot allocate memory

hab ich vorher noch nie gesehen!
Weil der OOM-Killer des Kernels schiesst wild um sich, trifft zwar meistens nicht den richtigen aber doch einen, damit man noch "ps ax" eingeben kann..
Und der wiregated(.pl) kanns ned sein, weil der wird vom Monit schon lang vorher erschossen..
Ich war jetzt mal so frei, anzufangen die Mails in /var/spool/exim4/msglog/ zu entsorgen, die kommen eh nie an..
Aber das löst nicht die Ursache, verzögert nur das sichtbare Problem.

Die beste, erste Massnahme wäre jetzt glaube ich mal diese Dinger aus der Crontab zu nehmen, weil die Wahrscheinlichkeit geht nahe gegen 100% das es daran liegt

Makki

[lio123]

selbst wenn's böse gemeint wäre-ich habe da größtes Verständnis, nicht nur Dir gegenüber.

den reboot habe ich gerade selbst ausgeführt.
Das kannst Du aber auch gern selbst machen-Wenn die Wartungsverbindung offen ist, brauchst Du nicht erst danach fragen ,-)

Ach ja, alle Sensoren, und auch USB-Zeugs ist momentan noch weg, Plugins aber aktiv

Wenn ich weiss, dass Du drin bist, unterlasse ich jede aktivität.
Ich wollte nämlich gerade das Verzeichnis löschen
/var/spool/exim4/msglog

[JuMi2006]

Zu 99.999% ist das sml-script schuld. ">/dev/null 2>&1" sorgt dafür dass keine Mail mit der Ausgabe des cronjobs erstellt wird. Zum besseren Verständnis lässt sich das ergooglen.

[makki]

Na siehste, geht doch, ich mein das ja nicht böse, auch wenns manchmal so klingt..

Nun Schritt für Schritt, wie man dahinter kommt, was da schiefläuft:

Einen Verdacht hatten wir alle ja schon..
Etwas "komprimiert"

lsof
..
root@wiregate534:~# ls -lA /var/spool/exim4/msglog/ | wc -l 
112870

haben wir schonmal 112.870 Übeltäter

Das Problem ist nun 50:50 hausgemacht:

2014-02-04 21:20:08 Received from root@wiregate1-mm.elabnet.com U=root P=local S=664
2014-02-04 21:20:09 SMTP error from remote mail server after RCPT TO:<root@wiregate1-mm.elabnet.com>: host mail1.elabnet.de [81.16.179.52]: 450 too many connections from your IP (rate controlled)
2014-02-04 21:20:09 root@wiregate1-mm.elabnet.com R=smarthost T=remote_smtp_smarthost defer (-44): SMTP error from remote mail server after RCPT TO:<root@wiregate1-mm.elabnet.com>: host mail1.elabnet.de [81.16.179.52]: 450 too many connections from your IP (rate controlled)
/var/spool/exim4/msglog/1WAmTU-0006Ta-Fx (END)

Mit

mailq

können wir uns das ganze Desaster dann auch nochmal ansehen.
(Sollte man aber ca. 30min Zeit zum ansehen mitbringen..)

Nun muss man (der interne Mailserver ist nicht "optimal Anwenderfreundlich" konfiguriert) aber noch den bösen Buben finden:

Weiter kam ich nicht, weil jetzt ist die Kiste "voll" und führt garkeinen Befehl mehr aus Remote reboots mache ich nicht ohne Absprache..

Edit: Aber irgendwas läuft da richtig schief, der Exim (Mailserver) alleine schafft das nicht, eben nochmal ausprobiert..

Makki