Hallo,
ich komme nicht mehr weiter. Es liegt nicht wie vermutet an der Fritzbox Labor version .. wol eher an meinem PI.
Fhem friert einfach ein. Logs füllen sich nicht mehr. Prozess ist noch Aktiv aber auch 0% CPU.
In den Logs steht nichts.
Verbose5 und auch stacktrace ist Aktiv
Es stehen nach einem absturz ganz normale dinge als letztes drin. Mal HM infos mal wetter abfrage aber nicht wieso fhem hängt...
habe absolut KEINE idee mehr.
Gibt es noch eine möglichkeit an mehr Logs zu kommen ?
Hi,
ich glaube wenn Du 0% CPU siehst (mit was?), bedeutet das nicht unbedingt, dass das System nicht voll ausgelastet ist.
Hier sind ein paar Tipps um das System zu analysieren (http://www.pc-erfahrung.de/linux/administration/linux-systemauslastung-analysieren.html), den per Console kommst Du ja noch drauf - oder?
Gruß Otto
Ja console klappt. Ich nutze top um mir das anzuzeigen
ZitatFhem friert einfach ein. Logs füllen sich nicht mehr. Prozess ist noch Aktiv aber auch 0% CPU.
Ist die Festplatte voll?
Falls nein: Funktioniert FHEMWEB? Was liefert "strace -p <FHEM-PID>" ?
also neuste Pi updates drauf.
Beim fhem.cfg speichern ewige Ladezeit .. und das wars nichts geht mehr.
festplatte zu 50% leer.
strace liefert :
-interrupt to quit recvform(105,
mehr passietr da nicht
Top zeigt an 10% mem in benutzung. Aber überall noch mehr als genug Frei ...
Habe es gekillt und lasse strace nun mal laufen bis es hängt ...
Kann ich den Inhalt speichern in eine Datei ? Da Kopieren aus Putty nicht so wirklich funktioniert bei mir.
Jetzt wuesste ich gerne, was 105 ist, siehe "ls -l /proc/<fhem-pid>/fd/105"
ZitatKann ich den Inhalt speichern in eine Datei ?
"strace -o /tmp/xy -p <pid>". Siehe auch "man strace"
Danke.
Da kommt :
startwatchdog und watchdog.pl
Das ist etwas altes was gar nicht mehr Aktiv ist die Dateien liegen im fhem root. Was auch immer diese damit zu tun haben ??
in der fhem.cfg ist dazu nichts.
Findest du denn etwas in deinen fhem Stardateien (bspw. /etc/init.d/fhem)?
Die schaut normal aus :
#!/bin/sh
# description: Start or stop the fhem server
# Added by Alex Peuchert
### BEGIN INIT INFO
# Provides: fhem.pl
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: FHEM server
### END INIT INFO
set -e
cd /opt/fhem
port=7072
case "$1" in
'start')
echo "Starting fhem..."
perl fhem.pl fhem.cfg
RETVAL=$?
;;
'stop')
echo "Stopping fhem..."
perl fhem.pl $port "shutdown"
RETVAL=$?
;;
'status')
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
echo "fhem is not running"
else
echo "fhem is running"
fi
;;
*)
echo "Usage: $0 { start | stop | status }"
RETVAL=1
;;
esac
exit $RETVAL
Hallo,
Zitat von: ChrisW am 15 August 2016, 14:17:42
Kann ich den Inhalt speichern in eine Datei ? Da Kopieren aus Putty nicht so wirklich funktioniert bei mir.
Windows und Putty: kopieren aus Putty: nur mit der Maus markeiren, der markierte Text landet automatisch im Clipboard.
Clipboard-Inhalt in Putty einfügen an der Cursorpositon: nur rechte Maustaste drücken.
Gruß aus Berlin
Michael
Nicht Windows da hat es damals funktioniert. ich nutze Linux ;)
Aber auch nicht weiter schlimm. Nun passiert natürlich wieder nichts. Läuft alles.
Unter Linux:
Markieren und mit "Mittlerer Maustaste" woanders einfügen ...
Soo nach langem warten ist es jetzt wieder passiert wohl schon wieder dieses Watchdog ... Woher auch immer das kommt.
Ich habe dies auch erst nach den ersten abstürzen ausprobiert.
Finde in Fhem nichts mehr !
gettimeofday({1471340300, 684929}, NULL) = 0
gettimeofday({1471340300, 687257}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340300, 693243}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340300, 698104}, NULL) = 0
select(112, [9 10 11 43 44 45 60 88 102 104 105], NULL, NULL, {2, 621853}) = 1 ( in [10], left {2, 321977})
read(10, "tAE7C72072C23\r\n", 255) = 15
gettimeofday({1471340301, 6785}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340301, 11429}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340301, 17758}, NULL) = 0
gettimeofday({1471340301, 21405}, NULL) = 0
gettimeofday({1471340301, 24110}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340301, 30872}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340301, 36010}, NULL) = 0
select(112, [9 10 11 43 44 45 60 88 102 104 105], NULL, NULL, {2, 283946}) = 1 ( in [10], left {0, 651478})
read(10, "tA0E581781615\r\n", 255) = 15
gettimeofday({1471340302, 676779}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340302, 681158}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340302, 686384}, NULL) = 0
gettimeofday({1471340302, 689280}, NULL) = 0
gettimeofday({1471340302, 691525}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340302, 696775}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340302, 701361}, NULL) = 0
select(112, [9 10 11 43 44 45 60 88 102 104 105], NULL, NULL, {0, 618596}) = 1 ( in [10], left {0, 326228})
read(10, "tAEE557057214\r\n", 255) = 15
gettimeofday({1471340303, 1824}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340303, 6641}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340303, 12345}, NULL) = 0
gettimeofday({1471340303, 16086}, NULL) = 0
gettimeofday({1471340303, 18725}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340303, 25301}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1471340303, 30392}, NULL) = 0
select(112, [9 10 11 43 44 45 60 88 102 104 105], NULL, NULL, {0, 289565}) = 0 ( Timeout)
gettimeofday({1471340303, 325984}, NULL) = 0
gettimeofday({1471340303, 334454}, NULL) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbec8e844) = -1 ENOTTY (Inappropriate i octl for device)
_llseek(5, 0, 0xbec8e890, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbec8e844) = -1 ENOTTY (Inappropriate i octl for device)
_llseek(5, 0, 0xbec8e890, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(5577), sin_addr=inet_addr("192.168 .2.46")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(8, NULL, [5], NULL, {2, 0}) = 1 (out [5], left {1, 994701})
connect(5, {sa_family=AF_INET, sin_port=htons(5577), sin_addr=inet_addr("192.168 .2.46")}, 16) = 0
fcntl64(5, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(5, F_SETFL, O_RDWR) = 0
getpeername(5, {sa_family=AF_INET, sin_port=htons(5577), sin_addr=inet_addr("192 .168.2.46")}, [16]) = 0
getpeername(5, {sa_family=AF_INET, sin_port=htons(5577), sin_addr=inet_addr("192 .168.2.46")}, [16]) = 0
send(5, "\357\1w", 3, 0) = 3
recvfrom(5, ^C <unfinished ...>
Process 2609 detached
root@raspberrypi:~# ls -I /proc/2609/fd/5
startwatchdog watchdog.pl
root@raspberrypi:~#
Ich lasse jetzt alles wie es ist und starte FHEM nicht mehr. Was kann ich nun noch versuchen?
Habe mal geschaut es läuft auch kein Watchdog ..
ps aux | grep perl
fhem 2609 5.0 11.3 55828 50504 ? S Aug15 66:39 perl fhem.pl fhem.cfg
root 19931 0.0 0.4 4160 1884 pts/0 S+ 12:29 0:00 grep perl
Ups ein fehler ich habe ls -I gemacht und nicht ls -l:
root@raspberrypi:~# ls -l /proc/2609/fd/5
lrwx------ 1 root root 64 Aug 16 12:43 /proc/2609/fd/5 -> socket:[63438]
Somit war das Watchdog nur der Inhalt von root ;)
Leider sagt mir das nun gar nichts was es mit deinem Problem zu tun hat
Zitatrecvfrom(5, ^C <unfinished ...>
...
lrwx------ 1 root root 64 Aug 16 12:43 /proc/2609/fd/5 -> socket:[63438]
FHEM wartet also auf Netzwerk-Daten. Mit
lsof | grep 63438kriegt man etwas mehr Details ueber diesen Netzwerk-Kanal, was hoffentlich reicht, um den Verursacher zu identifizieren. Am besten im Problemfall vor FHEM-Neustart die Ausgabe von lsof in einer Datei sichern.
aha ...
ergebniss:
perl 2609 fhem 5u IPv4 63438 0t0 TCP RaspBerry-FHEM.fritz.box:47483->WIFILED-KUECHE.fritz.box:5577 (ESTABLISHED)
Das ist :
define wifiledkueche LW12 192.168.2.46
attr wifiledkueche room Lampen
attr wifiledkueche webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:toggle:on:off:dim
Das LW12 Modul wartet auf Daten von der Gegenstelle (WIFILED-KUECHE), aber der Gegenstelle ist gerade nicht nach Senden.
Leider verwendet das LW12 Modul nicht die von FHEM fuer diesen Zweck angebotene Funktionen, sondern "kocht" sein eigenes, blockierendes Sueppchen.
ja scheint so normal sollte so etwas ja auch nicht zu einem absturz führen.
Das ganze ist erst aufgefallen nach dem Fritzbox Labor Update. Dort wurde ein WLAn Update gemacht das er automatisch wechselt usw. ..
Das mögen wohl einige Wlan Geräte im Haus nicht. Habe es nun rausgenommen und hoffe es läuft rum.
Wird sicher eine alternative geben muss ich am Wochenende mal schauen.
Vielen Dank für die ganze Hilfe ;) Hoffe es ist nun erledigt.