Hallo,
Ich bin mit meinem System von einem Cubitruck auf einen anderen umgezogen seit dem bekomme ich diese Fehlermeldung:
2016.05.06 11:50:57 1 : writing /opt/fhem/FHEM/controls_fhem.txt failed: , trying to restore the previous version and aborting the update
Hatte schon versucht die Rechte anzupassen und zu ändern kommt aber immer wieder die gleiche Fehlermeldung, könnte mir da jemand vielleicht helfen???
Sonst klappt alles...
Mfg Steffen
Hallo,
Habe jetzt mal die "controls_fhem.txt" gelöscht und ein update durch geführt aber die gleiche Fehlermeldung kommt wieder, keine Ahung was ich jetzt noch machen könnte?!? :-\
Mfg Steffen
Rechte im Verzeichnis angeschaut?
Was heißt "versucht, die Rechte anzupassen" ? Welche Rechte ? Auf was anzupassen ? Mit welchem Kommando ? Mit welchem Erfolg ?
Ohne weitere Detailinformationen ist das nicht zu behandeln.
LG
pah
Hallo,
ja stimmt, hätte ich gleich liefern sollen...
root@cubietruck:/opt/fhem/FHEM# ls -l
-rwxrwxrwx 1 fhem dialout 115334 May 7 08:50 controls_fhem.txt
damit habe ich versucht die Rechte anzupassen:
chmod 777 controls_fhem.txt
chown fhem:dialout controls_fhem.txt
Mfg Steffen
Lösche die Datei einfach und starte das update dann nochmal neu.
Nebenbei angemerkt: Mich würden viel weniger die Rechte auf die einzelne Datei interessieren als vielmehr die Rechte auf das gesamte Verzeichnis.
Mach doch mal folgendes:
chown -R fhem:dialout /opt/fhem/
Zitat von: betateilchen am 07 Mai 2016, 14:39:36
Lösche die Datei einfach und starte das update dann nochmal neu.
Nebenbei angemerkt: Mich würden viel weniger die Rechte auf die einzelne Datei interessieren als vielmehr die Rechte auf das gesamte Verzeichnis.
Mach doch mal folgendes:
chown -R fhem:dialout /opt/fhem/
Hallo,
Ok hatte ich versucht, also Datei gelöscht und Update aber immer noch die gleiche Fehlermeldung.
Hier mal die Recht von den Verzeichnissen:
root@cubietruck:/opt# ls -l
total 12
drwxrwxrwx 18 fhem dialout 4096 May 2 21:48 fhem
drwxr-xr-x 2 fhem dialout 4096 May 2 20:43 yowsup-config
drwxr-xr-x 3 fhem dialout 4096 Apr 24 11:36 yowsup-master
root@cubietruck:/opt# cd fhem
root@cubietruck:/opt/fhem# ls -l
total 716
drwxrwxrwx 2 fhem dialout 4096 Apr 30 17:50 backup
drwxrwxrwx 2 fhem dialout 4096 May 1 19:59 cache
drwxrwxrwx 2 fhem dialout 4096 May 1 19:59 cert_neu
drwxrwxrwx 2 fhem dialout 4096 May 2 21:28 certs
-rwxrwxrwx 1 fhem dialout 147343 May 7 14:47 CHANGED
-rwxrwxrwx 1 fhem dialout 54311 Apr 30 17:50 config
-rwxrwxrwx 1 fhem dialout 33169 May 7 14:47 configDB.pm
drwxrwxrwx 40 fhem dialout 4096 May 1 19:59 contrib
drwxrwxrwx 3 fhem dialout 4096 May 1 12:43 demolog
drwxrwxrwx 4 fhem dialout 4096 May 1 19:59 docs
drwxrwxrwx 5 fhem dialout 20480 May 7 14:49 FHEM
-rwxrwxrwx 1 fhem dialout 59880 May 7 08:12 fhem.cfg
-rwxrwxrwx 1 fhem dialout 15692 May 7 14:47 fhem.cfg.demo
-rwxrwxrwx 1 fhem dialout 57397 Apr 30 17:50 fhem.cfg.save
-rwxrwxrwx 1 fhem dialout 123597 May 7 14:47 fhem.pl
-rwxrwxrwx 1 fhem dialout 2984 Apr 30 17:50 homebild2.jpg
-rwxrwxrwx 1 fhem dialout 78149 Apr 30 17:50 homebild.jpg
-rwxrwxrwx 1 fhem dialout 630 Apr 30 17:50 HueSideBoard-2014-06.log
-rwxrwxrwx 1 fhem dialout 8607 Apr 30 17:50 images.jpg
-rwxrwxrwx 1 fhem dialout 9384 Sep 29 2015 lepresenced
-rwxrwxrwx 1 fhem dialout 1107 Apr 30 17:50 lescan3.sh
-rwxrwxrwx 1 fhem dialout 1107 Apr 30 17:50 lescan.sh
drwxrwxrwx 2 fhem dialout 20480 May 3 06:52 log
drwxrwxrwx 2 fhem dialout 4096 May 1 20:02 pr
-rwxrwxrwx 1 fhem dialout 5274 Mar 4 18:42 presenced-1.4.deb
-rwxrwxrwx 1 fhem dialout 761 Apr 30 17:50 README_DEMO.txt
drwxrwxrwx 5 fhem dialout 4096 May 7 07:39 restoreDir
drwxrwxrwx 2 fhem dialout 4096 May 1 20:02 unused
drwxrwxrwx 12 fhem dialout 4096 May 1 20:05 www
drwxrwxrwx 3 fhem dialout 4096 May 2 20:32 yowsup
root@cubietruck:/opt/fhem#
Mfg Steffen
Wenn ich das richtig sehe, wird auch nach dem Löschen die Datei mit Inhalt und Rechten wieder angelegt (siehe 5.Post), dann liegt es vielleicht gar nicht an den Rechten etc.
Die Meldung kommt eigentlich erst, wenn die Datei erfolgreich geöffnet wurde aber beim Schreiben etwas passiert.
Ausserdem müsste die Meldung eigentlich eine Fehlermeldung vom Betriebssystem tragen, diese fehlt aber hier, also ist möglicherweise auf OS-Ebene alles gut gegangen. Trotzdem wurden nicht soviele Bytes geschrieben wie erwartet.
Kannst Du etwas sagen was zu der Fehlermeldung führt --> Stösst Du manuell ein Update an, gibt es sonst etwas was schief geht andere unerklärliche Meldungen, gab es die Meldung auch vor dem Umzug, wie hast Du den Umzug gemacht etc
Ich nehme an, dass die Hardware identisch ist - oder hat es da eine Änderung gegeben ? Evtl. im EEPROM statt auf einer SD-Karte ?
Was sagt das System, wenn einfach die Karte in den anderen Cubietruck geschoben wird ?
LG
pah
Hallo,
Also vor dem Umzug hatte ich diese Fehlermeldung nicht, die Trat genau danach auf.
Ich habe zwei Cubitruck, auf dem alten System lief Debian Wheezy und auf dem neu aufgelegten jetzt Jessie.
Das einzige was jetzt anders ist das ich vorher Boot von Nand hatte und Rootfs auf Hdd,
jetzt ist es Boot von SDKarte aber trotzdem Rootfs auf Hdd.
Fehlermeldungen habe ich nur diese eine hier im log, die ist auch erst nach dem Umzug aufgetreten:
2016.05.09 05:20:26 1: FHEMWEB SSL/HTTPS error: kann aber Trotzdem per https auf meine Seite zugreifen,
wenn ich Fhem per Shell starte erhalte ich auch keine Fehlermeldungen.
Sonst Funktioniert alles wie es soll bis auf das eine "writing /opt/fhem/FHEM/controls_fhem.txt failed"
Habt ihr vielleicht noch eine Idee wo man nach Fehler suchen könnte?
Mfg Steffen
Nochmal die Frage von oben, wie kommt es zu dieser Fehlermeldung:
Zitat von: viegener am 08 Mai 2016, 11:27:14
Kannst Du etwas sagen was zu der Fehlermeldung führt --> Stösst Du manuell ein Update an
Es wäre auch interessant, ob der Update denn überhaupt läuft?
Funktioniert ein updatecheck?
Achso und noch einer, ich habe nochmal in den Code geschaut:
Die Meldung kommt, wenn die Anzahl der Bytes die FHEM versucht zu schreiben und die Grösse der Datei die der perl "-s" operator zurückliefert.
Hast Du dieselbe perlversion auf beiden Rechnern?
Hallo,
Habe gerade doch was gefunden im Log und zwar das hier:
2016.05.10 06:35:30 1: RMDIR: /opt/fhem/restoreDir/2016-05-06
2016.05.10 06:35:30 1: UPD ./CHANGED
2016.05.10 06:35:30 1: UPD ./fhem.pl
2016.05.10 06:35:31 1: UPD FHEM/00_FBAHAHTTP.pm
2016.05.10 06:35:31 1: UPD FHEM/00_ZWDongle.pm
2016.05.10 06:35:31 1: UPD FHEM/10_CUL_HM.pm
2016.05.10 06:35:31 1: UPD FHEM/10_FBDECT.pm
2016.05.10 06:35:31 1: UPD FHEM/31_HUEDevice.pm
2016.05.10 06:35:31 1: UPD FHEM/37_plex.pm
2016.05.10 06:35:31 1: UPD FHEM/93_DbLog.pm
2016.05.10 06:35:31 1: UPD FHEM/98_HMinfo.pm
2016.05.10 06:35:31 1: UPD FHEM/HMConfig.pm
2016.05.10 06:35:31 1: UPD FHEM/SetExtensions.pm
2016.05.10 06:35:31 1: UPD www/images/fhemSVG/gasoline.svg
2016.05.10 06:35:32 1:
2016.05.10 06:35:32 1: New entries in the CHANGED file:
2016.05.10 06:35:32 1: - feature: added new module 37_plex.pm
2016.05.10 06:35:32 1: - feature: FBAHAHTTP module as replacement for the deprecated FBAHA
[color=red]2016.05.10 06:35:32 1: PERL WARNING: Use of uninitialized value $written in numeric ne (!=) at /opt/fhem/FHEM/98_update.pm line 546.
2016.05.10 06:35:32 3: stacktrace:
2016.05.10 06:35:32 3: main::__ANON__ called by /opt/fhem/FHEM/98_update.pm (546)
2016.05.10 06:35:32 3: main::upd_writeFile called by /opt/fhem/FHEM/98_update.pm (390)
2016.05.10 06:35:32 3: main::doUpdate called by /opt/fhem/FHEM/98_update.pm (218)
2016.05.10 06:35:32 3: main::doUpdateLoop called by /opt/fhem/FHEM/98_update.pm (183)
2016.05.10 06:35:32 3: main::doUpdateInBackground called by /opt/fhem/FHEM/Blocking.pm (88)
2016.05.10 06:35:32 3: main::BlockingCall called by /opt/fhem/FHEM/98_update.pm (73)
2016.05.10 06:35:32 3: main::CommandUpdate called by fhem.pl (1071)
2016.05.10 06:35:32 3: main::AnalyzeCommand called by fhem.pl (941)
2016.05.10 06:35:32 3: main::AnalyzeCommandChain called by /opt/fhem/FHEM/01_FHEMWEB.pm (2192)
2016.05.10 06:35:32 3: main::FW_fC called by /opt/fhem/FHEM/01_FHEMWEB.pm (751)
2016.05.10 06:35:32 3: main::FW_answerCall called by /opt/fhem/FHEM/01_FHEMWEB.pm (446)
2016.05.10 06:35:32 3: main::FW_Read called by fhem.pl (3169)
2016.05.10 06:35:32 3: main::CallFn called by fhem.pl (658)[/color]
2016.05.10 06:35:32 1: writing /opt/fhem/FHEM/controls_fhem.txt failed: , trying to restore the previous version and aborting the update
könnte diese Fehlermeldung was damit zu tun haben?
hier nochmal vom Webinterface:
Events (Filter: global) FHEM log Reset
2016.05.10 06:35:30 1 : RMDIR: /opt/fhem/restoreDir/2016-05-06
2016.05.10 06:35:30 1 : UPD ./CHANGED
2016.05.10 06:35:30 1 : UPD ./fhem.pl
2016.05.10 06:35:31 1 : UPD FHEM/00_FBAHAHTTP.pm
2016.05.10 06:35:31 1 : UPD FHEM/00_ZWDongle.pm
2016.05.10 06:35:31 1 : UPD FHEM/10_CUL_HM.pm
2016.05.10 06:35:31 1 : UPD FHEM/10_FBDECT.pm
2016.05.10 06:35:31 1 : UPD FHEM/31_HUEDevice.pm
2016.05.10 06:35:31 1 : UPD FHEM/37_plex.pm
2016.05.10 06:35:31 1 : UPD FHEM/93_DbLog.pm
2016.05.10 06:35:31 1 : UPD FHEM/98_HMinfo.pm
2016.05.10 06:35:31 1 : UPD FHEM/HMConfig.pm
2016.05.10 06:35:31 1 : UPD FHEM/SetExtensions.pm
2016.05.10 06:35:31 1 : UPD www/images/fhemSVG/gasoline.svg
2016.05.10 06:35:32 1 :
2016.05.10 06:35:32 1 : New entries in the CHANGED file:
2016.05.10 06:35:32 1 : - feature: added new module 37_plex.pm
2016.05.10 06:35:32 1 : - feature: FBAHAHTTP module as replacement for the deprecated FBAHA
2016.05.10 06:35:32 1 : PERL WARNING: Use of uninitialized value $written in numeric ne (!=) at /opt/fhem/FHEM/98_update.pm line 546.
2016.05.10 06:35:32 3 : stacktrace:
2016.05.10 06:35:32 3 : main::__ANON__ called by /opt/fhem/FHEM/98_update.pm (546)
2016.05.10 06:35:32 3 : main::upd_writeFile called by /opt/fhem/FHEM/98_update.pm (390)
2016.05.10 06:35:32 3 : main::doUpdate called by /opt/fhem/FHEM/98_update.pm (218)
2016.05.10 06:35:32 3 : main::doUpdateLoop called by /opt/fhem/FHEM/98_update.pm (183)
2016.05.10 06:35:32 3 : main::doUpdateInBackground called by /opt/fhem/FHEM/Blocking.pm (88)
2016.05.10 06:35:32 3 : main::BlockingCall called by /opt/fhem/FHEM/98_update.pm (73)
2016.05.10 06:35:32 3 : main::CommandUpdate called by fhem.pl (1071)
2016.05.10 06:35:32 3 : main::AnalyzeCommand called by fhem.pl (941)
2016.05.10 06:35:32 3 : main::AnalyzeCommandChain called by /opt/fhem/FHEM/01_FHEMWEB.pm (2192)
2016.05.10 06:35:32 3 : main::FW_fC called by /opt/fhem/FHEM/01_FHEMWEB.pm (751)
2016.05.10 06:35:32 3 : main::FW_answerCall called by /opt/fhem/FHEM/01_FHEMWEB.pm (446)
2016.05.10 06:35:32 3 : main::FW_Read called by fhem.pl (3169)
2016.05.10 06:35:32 3 : main::CallFn called by fhem.pl (658)
2016.05.10 06:35:32 1 : writing /opt/fhem/FHEM/controls_fhem.txt failed: , trying to restore the previous version and aborting the update
hier auch meine Perl Version, was ich auf dem Altem Cubituck drauf hatte kann ich leider nicht mehr sagen:
root@cubietruck:~# perl -v
This is perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int
Mfg Steffen
was macht denn ein "update force"?
wenn ich Fhem per Shell starte erhalte ich auch keine Fehlermeldungen.
Unter welchem User läuft den Dein fhem?
ps aux | grep fhem
Und bitte, nicht immer ein chmod 777, damit hebelst Du jede Sicherheitsbestimmung des Servers aus
root@cubietruck:~# ps aux | grep fhem
root 949 0.3 0.3 21264 7260 ? Ssl May07 13:50 /usr/bin/perl /opt/fhem/lepresenced -d -a 0.0.0.0
fhem 4221 0.0 0.6 28504 12656 ? S May08 1:39 python /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
fhem 4291 0.0 0.6 28504 12656 ? S May08 1:39 python /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
fhem 6630 2.5 3.2 72568 66176 ? S May09 42:25 perl fhem.pl fhem.cfg
fhem 6634 0.0 0.0 0 0 ? Z May09 0:00 [perl] <defunct>
fhem 6635 0.0 0.0 0 0 ? Z May09 0:00 [perl] <defunct>
fhem 7665 0.0 0.6 37652 13324 ? Sl May09 0:57 python /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
root 10198 0.0 0.0 3668 764 pts/0 R+ 10:02 0:00 grep fhem
Im Anhang das Log vom Update Force.
gebe die vollkommen recht, hatte nur chmod 777 um Brechtigungsprobleme auszuschließen!
Mfg Steffen
ohne Fehlermeldung?
hast du noch irgendwelche attr fürs update gesetzt?
Nochmals meine Frage:
Unter welchem user läuft fhem, bzw. soll laufen?
Zitat von: Wernieman am 10 Mai 2016, 10:11:59
Nochmals meine Frage:
Unter welchem user läuft fhem, bzw. soll laufen?
root@cubietruck:~# ps aux | grep fhem
root 949 0.3 0.3 21264 7260 ? Ssl May07 13:50 /usr/bin/perl /opt/fhem/lepresenced -d -a 0.0.0.0
fhem 4221 0.0 0.6 28504 12656 ? S May08 1:39 python /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
fhem 4291 0.0 0.6 28504 12656 ? S May08 1:39 python /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
fhem 6630 2.5 3.2 72568 66176 ? S May09 42:25 perl fhem.pl fhem.cfg
fhem 6634 0.0 0.0 0 0 ? Z May09 0:00 [perl] <defunct>
fhem 6635 0.0 0.0 0 0 ? Z May09 0:00 [perl] <defunct>
fhem 7665 0.0 0.6 37652 13324 ? Sl May09 0:57 python /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
root 10198 0.0 0.0 3668 764 pts/0 R+ 10:02 0:00 grep fhem
Ich hoffe das meintest du?!?
Mfg Steffen
Du hast ein Problem:
fhem 6634 0.0 0.0 0 0 ? Z May09 0:00 [perl] <defunct>
fhem 6635 0.0 0.0 0 0 ? Z May09 0:00 [perl] <defunct>
2 laufen 2! Zombis in Deinem System. Gans einfach am "Z" zu sehen.
Ich würde erstmal dieses "Problem" lösen:
Wer hat diese gestartet?
ps -o ppid 6634
ps -o ppid 6635
Eventuell must Du erst den Master dieser Prozesse "killen"
Dann die nächste Frage, warum hast Du 3 yowsup-cli Prozesse?
Und .. nur kenne ich mich damit nicht aus ... muß der lepresenced-Deamon wirklich als root laufen?
Hallo,
hier der Master glaube ich:
root@cubietruck:~# ps -o ppid 6634
PPID
6630
root@cubietruck:~# ps -o ppid 6635
PPID
6630
root@cubietruck:~# ps xa
PID TTY STAT TIME COMMAND
1 ? Ss 0:19 /sbin/init sunxi_no_mali_mem_reserve
2 ? S 0:00 [kthreadd]
3 ? S 0:08 [ksoftirqd/0]
6 ? S 0:00 [migration/0]
7 ? S 0:00 [migration/1]
8 ? S 0:00 [kworker/1:0]
9 ? S 0:20 [ksoftirqd/1]
10 ? S< 0:00 [cpuset]
11 ? S< 0:00 [khelper]
12 ? S 0:00 [kdevtmpfs]
13 ? S< 0:00 [netns]
14 ? S 0:03 [sync_supers]
15 ? S 0:00 [bdi-default]
16 ? S< 0:00 [kintegrityd]
17 ? S< 0:00 [crypto]
18 ? S< 0:00 [kblockd]
19 ? S 0:00 [khubd]
20 ? S< 0:00 [cpufreq_uevent]
22 ? S< 0:00 [cfg80211]
24 ? S< 0:00 [rpciod]
25 ? S 0:00 [khungtaskd]
26 ? S 0:00 [kswapd0]
27 ? SN 0:00 [ksmd]
28 ? S 0:00 [fsnotify_mark]
29 ? S 0:00 [ecryptfs-kthrea]
30 ? S< 0:00 [nfsiod]
31 ? S< 0:00 [cifsiod]
32 ? S 0:00 [jfsIO]
33 ? S 0:00 [jfsCommit]
34 ? S 0:00 [jfsCommit]
35 ? S 0:00 [jfsSync]
36 ? S< 0:00 [xfsalloc]
37 ? S< 0:00 [xfs_mru_cache]
38 ? S< 0:00 [xfslogd]
52 ? S 0:00 [nandd]
53 ? S 0:00 [nfmtd]
54 ? S 0:00 [scsi_eh_0]
55 ? S 1:30 [kworker/u:1]
56 ? S< 0:00 [bond0]
57 ? S 0:11 [kworker/u:2]
64 ? S< 0:00 [kmpathd]
65 ? S< 0:00 [kmpath_handlerd]
66 ? S 4:27 [cfinteractive]
67 ? S< 0:00 [binder]
68 ? S< 0:00 [codec_resume]
69 ? S 2:16 [hdmi proc]
70 ? S< 0:00 [deferwq]
101 ? S 0:00 [mmcqd/0]
128 ? S 0:00 [jbd2/sda1-8]
129 ? S< 0:00 [ext4-dio-unwrit]
164 ? S 0:00 [kauditd]
166 ? Ss 0:26 /lib/systemd/systemd-journald
170 ? Ss 0:00 /lib/systemd/systemd-udevd
171 ? S< 0:00 [krfcommd]
181 ? S 0:14 [flush-8:0]
195 ? S 0:00 [dhd_cfg80211_ev]
197 ? S 0:00 [dhd_watchdog]
202 ? S 0:00 [dhd_dpc]
203 ? S 0:00 [dhd_sysioc]
254 ? S< 0:00 [hci0]
299 ? S 5:00 [kworker/1:2]
324 ? S 0:00 [jbd2/mmcblk0p1-]
325 ? S< 0:00 [ext4-dio-unwrit]
506 ? Ss 3:32 /usr/lib/bluetooth/bluetoothd
507 ? Ss 0:59 /usr/sbin/haveged --Foreground --verbose=1 --write=10
508 ? Ss 0:00 /usr/sbin/cron -f
509 ? Ss 0:04 /usr/sbin/sshd -D
511 ? Ss 0:02 /lib/systemd/systemd-logind
556 ? Ss 0:00 /usr/bin/dbus-daemon --system --address=systemd: --no
573 ? Ss 0:00 /usr/sbin/lircd --driver=devinput --device=/dev/input
596 ? Ss 0:43 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/nt
598 ? Ssl 0:04 /usr/sbin/rsyslogd -n
614 tty1 Ss+ 0:00 /sbin/agetty --noclear tty1 linux
615 ttyS0 Ss+ 0:00 /sbin/agetty -L 115200 ttyS0 screen.linux
657 ? S 1:23 /usr/bin/perl /usr/sbin/presenced -d -P /var/run/pres
668 ? Sl 13:19 /usr/bin/perl /usr/sbin/collectord -c /etc/collectord
751 ? Ss 0:18 /usr/sbin/nmbd -D
763 ? Ss 0:33 /usr/sbin/smbd -D
766 ? S 0:03 /usr/sbin/smbd -D
853 ? Ss 0:00 /lib/systemd/systemd --user
854 ? S 0:00 (sd-pam)
949 ? Ssl 14:08 /usr/bin/perl /opt/fhem/lepresenced -d -a 0.0.0.0
951 ? S 2:12 hcitool -i hci0 lescan --duplicates
4221 ? S 1:42 python /opt/yowsup-master/yowsup-cli demos -c /opt/yo
4291 ? S 1:42 python /opt/yowsup-master/yowsup-cli demos -c /opt/yo
6630 ? S 45:08 perl fhem.pl fhem.cfg
6634 ? Z 0:00 [perl] <defunct>
6635 ? Z 0:00 [perl] <defunct>
7665 ? Sl 1:01 python /opt/yowsup-master/yowsup-cli demos -c /opt/yo
10314 ? S 0:00 [kworker/0:0]
10335 ? S 0:00 [kworker/0:1]
10345 ? Ss 0:00 sshd: root@pts/0
10432 pts/0 Ss 0:00 -bash
10440 pts/0 R+ 0:00 ps xa
Warum yowsup 3x läuft kann ich leider auch nicht sagen, hatte es aus der Anleitung Installiert und dann nur meinen schlüssel den ich aus dem alten System per Editor wieder eingefügt, besser kenne ich mich leider auch nicht damit aus!
Soll ich die Prozesse erstmal killen?
Mfg Steffen
also ich habe auch solche "Zombies" und nicht die mords Ahnung von Linux, aber wenn du den Hauptprozess (der die Zombies mal gestartet hat) abschießt, schießt du damit definitv fhem ab.
und ich behaupte einfach mal so frech weg, dass die Zombies auch nicht die Ursache deines Problems sind.
hattest du nun irgendwelche Attribute unter global gesetzt, die update betreffen?
ein "attr global exclude_from_update ..." müsste da schon mal stehen... evtl. noch weitere?
Fahre mal Dein fhem (nur fhem) sauber herunter. Dann würde ich "aufräumen" und wider sauber starten ... eventuell hat einer dieser Prozesse die fhem.cfg "geblockt"
Edit:
Es kann, muß aber nicht die Ursache haben. Aber Fehlersuche auf einem "unsauberen" System ... ist schwierig.
Entsprechend möchte ich "automatisierer" Aussage nicht unterschrieben
bananapi@bapiFHEM ~ $ ps aux|grep fhem
fhem 580 9.3 5.1 51236 45876 pts/0 S 12:29 0:49 perl fhem.pl fhem.cfg
fhem 604 0.0 0.0 0 0 pts/0 Z 12:29 0:00 [perl] <defunct>
fhem 606 0.0 0.0 0 0 pts/0 Z 12:29 0:00 [perl] <defunct>
fhem 607 0.0 0.0 0 0 pts/0 Z 12:29 0:00 [perl] <defunct>
fhem 610 0.0 0.0 0 0 pts/0 Z 12:29 0:00 [perl] <defunct>
fhem 612 0.0 0.0 0 0 pts/0 Z 12:29 0:00 [perl] <defunct>
bananapi 775 0.0 0.1 3616 916 pts/0 S+ 12:38 0:00 grep --color=auto fhem
bananapi@bapiFHEM ~ $ sudo service fhem stop
Stopping fhem...
bananapi@bapiFHEM ~ $ ps aux|grep fhem
bananapi 801 0.0 0.0 3612 852 pts/0 S+ 12:38 0:00 grep --color=auto fhem
bananapi@bapiFHEM ~ $ sudo service fhem start
Starting fhem...
bananapi@bapiFHEM ~ $ ps aux|grep fhem
fhem 812 69.2 4.0 42380 36700 pts/0 S 12:38 0:08 perl fhem.pl fhem.cfg
fhem 838 0.4 0.0 0 0 pts/0 Z 12:38 0:00 [perl] <defunct>
fhem 839 0.4 0.0 0 0 pts/0 Z 12:38 0:00 [perl] <defunct>
fhem 842 0.4 0.0 0 0 pts/0 Z 12:38 0:00 [perl] <defunct>
fhem 843 0.4 0.0 0 0 pts/0 Z 12:38 0:00 [perl] <defunct>
bananapi 847 0.0 0.1 3616 916 pts/0 S+ 12:39 0:00 grep --color=auto fhem
bananapi@bapiFHEM ~ $
so schaut das bei mir aus, keinen Plan warum diese toten Prozesse da sind, aber die verschwinden mit dem stoppen von FHEM und tauchen mit nem Neustart wieder auf...
EDIT:
daher kommen die Zombies bei mir:
2016.05.10 12:39:56 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 843
2016.05.10 12:39:56 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 842
2016.05.10 12:39:56 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 839
2016.05.10 12:39:56 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 838
Zitat von: Steffen am 10 Mai 2016, 06:41:13
Hallo,
Habe gerade doch was gefunden im Log und zwar das hier:
2016.05.10 06:35:32 1: - feature: FBAHAHTTP module as replacement for the deprecated FBAHA
[color=red]2016.05.10 06:35:32 1: PERL WARNING: Use of uninitialized value $written in numeric ne (!=) at /opt/fhem/FHEM/98_update.pm line 546.
könnte diese Fehlermeldung was damit zu tun haben?
Ja genau diese Fehlermeldung ist das Problem. Die Feststellung der Dateigrösse (in perl "-s") liefert undef zurück (anstatt die Anzahl der Bytes in der Datei) und dann geht der Vergleich mit der Menge der Daten schief (Zeile 546 in Update) und der Fehler wird geworfen. Allerdings wird wohl von -s keine Fehlermeldung erzeugt, denn die ist in der Meldung leer...
Also müsste festgestellt werden warum Dein perl bei "-s" auf die datei undef ohne Fehlermeldung zurückliefert.
Die Zombies des FHEM-Prozesses sind sicher etwas was erstmal entfernt sein sollte, da nicht sicher ist welchen Einfluss das haben kann. Für den Moment wäre es vielleicht gut den cubietruck mal komplett neu zu starten und mit frisch gestartetem fhem zu schauen ob der update durchläuft?
Wenn das nicht passiert könnte man mit Debug-Ausgaben im Updatemodul schauen was genau passiert und warum die Dateigrösse nicht bestimmt wird.
Frage: Lief FHEM auch schon unter perl 5.20 auf dem alten Rechner?
Zitatund ich behaupte einfach mal so frech weg, dass die Zombies auch nicht die Ursache deines Problems sind.
Das halte ich tatsächlich für eine sehr gewagte Aussage von jemandem, der nach eigenem Bekunden nicht die "mords" Ahnung hat.
Schau mal bei Google unter "Linux zombies blocking files" => mehr als 1 Mio Links...(Achtung, "Linux" nicht vergessen, sonst landet bei menschlichen Zombies...)
LG
pah
Was passiert denn wenn Du in fhemweb (im Browser) folgendes Kommando eingibst:
{ my $test = -s "/opt/fhem/FHEM/controls_fhem.txt";; return "Result: ".(defined($test)?$test:"<undef>") }
Damit könnte man eingrenzen, ob das Problem nur während des Updates mit der Datei oder generell auftaucht?
Zitat von: viegener am 10 Mai 2016, 19:18:12
Was passiert denn wenn Du in fhemweb (im Browser) folgendes Kommando eingibst:
{ my $test = -s "/opt/fhem/FHEM/controls_fhem.txt";; return "Result: ".(defined($test)?$test:"<undef>") }
Damit könnte man eingrenzen, ob das Problem nur während des Updates mit der Datei oder generell auftaucht?
Guten Morgen,
bei der Eingabe bekomme ich das als Antwort:
Result: 115492
ich sags nochmal: kann es möglich sein, dass du irgendwelche attribute gesetzt hast die Update betreffen, z.B. irgendwelche Standard-Ordner geändert, die nun nach dem Umzug auf das neue System nicht mehr stimmen?
Zitat von: Steffen am 11 Mai 2016, 06:59:30
Guten Morgen,
bei der Eingabe bekomme ich das als Antwort:
Result: 115492
Damit ist jetzt zumindest klar, dass generell "-s" funktioniert und einen sinnvollen Wert zurückliefert.
Jetzt bleibt zu klären, warum direkt nach dem Schreiben auf dieselbe Datei undef zurückgeliefert wird.
Ist denn der Server inzwischen neu gestartet (und ohne Zombieprozesse)?
Hast Du direkt nach dem Start (wiederum ohne Zombies) einmal den update laufen lassen ?
Hallo,
Ich hatte den Server jetzt neu gestartet und gleich ein Update ausgeführt aber der gleiche Fehler und die Zombies bleiben...wenn ich Fhem per shell runterfahre dann verschwinden auch die Zombies, wenn ich Fhem wieder starte dann kommen die "Z" wieder...
Mfg Steffen
Diese Zombies habe ich auch. Bei mir kommen die von ein paar Lan-Pings. Die Pings funktionieren aber dennoch alle. Vermute das es mit dem Start von FHEM zusammen zu hängen, evtl. ist das System dann grad überlastet. Wenn ich die Pings auf disable 1 setze und nach dem start von fhem wieder auf disable 0, dann gibts keine Zombies. Aber mich haben sie noch nicht gestört...
Ich habe auch noch Zeit damit verbracht mich über Linux Zombies zu informieren. Von Datei blockierungen habe ich nirgends etwas gelesen (was natürlich immer noch nicht bedeutet, dass es unmöglich ist). Allerdings werden die PID's blockiert und das kann irgendwann problematisch werden, da deren Anzahl begrenzt ist.
Ich denke wir sind in der Phase Ursachen auszuschliessen (und die Zombies waren ein Kandidat und sind es vielleicht immer noch)?
Generell bin ich etwas ratlos und mein Vorschlag wäre Debugs in 98_update einzubauen, aber ich weiss nicht ob jemand anders eine bessere Idee hat?
(Dazu wäre es wichtig genau zu schauen welche Version 98_update hat -> also etwas wie
# $Id: 98_update.pm 10942 2016-02-26 11:08:14Z rudolfkoenig $
in der Datei.
Die Frage nach der perl-Version auf dem alten cubie ist allerdings noch offen.
Hier etwas zum Thema
ZitatIf some process has the pipe open for writing and O_NONBLOCK is clear, read() shall block the calling thread until some data is written or the pipe is closed by all processes that had the pipe open for writing.
http://linux.die.net/man/3/read
LG
pah
Zitat von: Prof. Dr. Peter Henning am 11 Mai 2016, 20:02:48
Hier etwas zum Thema
http://linux.die.net/man/3/read
LG
pah
Ich bin nicht ganz sicher ob ich den Vorschlag verstehe, glaubst Du dass die Dateigrösse nicht gelesen werden kann, weil sie noch geöffnet ist?
Da bin ich mir auch nicht sicher - aber vor allem zeigt dieser Auszug, dass Zombies sehr wohl Dateien blockieren können.
Aus dem Bauch heraus: Irgendetwas stimmt nicht mit dem Dateisystem. Operationen auf den Dateien werden nicht abgeschlossen, die Subprozesse hängen und warten.
Spaßeshalber könnte man eine RAMDisk anlegen, den ganzen FHEM-Kram darauf kopieren und die RAMDisk dann über das FHEM-Verzeichnis mounten.
LG
pah
Ja, das Zombies Dateien/Handles blockieren können kaufe ich
Ob das das Problem auslöst weiss ich noch nicht. Selbst wenn die Datei blockiert ist, müsste ein Zugriff auf die Dateigrösse trotzdem ein Ergebnis liefern (zur Not halt 0). Ich weiss zwar nicht wie -s implementiert ist, aber ein Zugriff auf die Metadaten der Datei (inkl. Grösse) sollte nicht durch den Öffnungsstatus der Datei beeinflusst werden. Der -s wird ja auf den Dateinamen und nicht auf den Filehandle durchgeführt.
Das Dateisystem könnte aber sehr wohl ein Problem haben, trotzdem ist das Verhalten nicht konsistent, denn nach dem Abbruch wird die alte Datei zurückkopiert (!) und nicht verschoben und dann scheint sie ja wieder vorhanden zu sein.
Sehr mysteriös ???
Achson: @Steffen: Gibt es Einträge im syslog?
Hallo,
Ich habe gerade geschaut aber nichts auffälliges finden können.
Da man den Fehler wohl ohne weiteres nicht so leicht finden wird, werde ich wohl das ganze nochmal neu aufsetzten,
vielleicht hat sich ja irgendwo ein Fehler eingeschlichen den ich nicht bemerkt habe!
Trotzdem vielen dank nochmal für eure Hilfe und Geduld...
Mfg Steffen
Also .. wir haben jetzt hier 2 Leute, die Zombiprozesse haben .... wir sollten debuggen, WARUM. Dieses ist schließlich nicht normal und darf e auch nicht werden.
Ich vermute, das es nicht direkt an den zombies liegt, sondern das die Ursache für die Zombies = der Ursache für das "Nichtschreiben" ist. Darf ich mal nach der perl-version fragen?
perl -v
P.S.
Die Aussage: "Schadet nicht, Stört mich nicht" ist so nicht gans richtig. Es ist eben KEIN Normales Systemverhalten und so etwas sollte man immer nachgehen. Nicht ohne Grund heißen diese Prozesse "Zombies" und kein "richtiger" Admin möchte diese haben ...
Mit "schadet nicht, Stört mich nicht" meinte ich eher den aktuellen Zustand meines Systems. Es gibt halt keine Auffälligkeiten, alles funktioniert so wie es soll. Das das mit den Zombies nicht normal ist, leucht mir wohl ein.
bei mir läuft Perl v5.14.2
Gruß
Ingo
Du hast geschrieben, nur wenn Du das "ping" Modul verwendest, hast Du Zombies?
Kannst Du mir (zum Testen) Deine Definition geben?
Richtig, wenn ich das PRESENCE Modul verwende, entstehen die bei einem Neustart.
Hab mal fix einen gemacht...
Die Meldungen im FHEM Log:
2016.05.12 12:59:23 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25824
2016.05.12 12:59:23 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25822
2016.05.12 12:59:23 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25820
2016.05.12 12:59:23 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25818
2016.05.12 12:59:23 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25816
2016.05.12 12:59:23 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25815
2016.05.12 12:59:22 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25812
2016.05.12 12:59:22 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25811
2016.05.12 12:59:15 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25809
2016.05.12 12:59:14 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25807
2016.05.12 12:59:14 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25805
2016.05.12 12:59:14 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 25803
hier einmal 'ps aux|grep fhem':
fhem 25779 17.9 5.1 51076 45692 ? S 12:58 0:43 /usr/bin/perl fhem.pl fhem.cfg
fhem 25803 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25805 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25807 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25809 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25811 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25812 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25815 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25816 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25818 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25820 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25822 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
fhem 25824 0.0 0.0 0 0 ? Z 12:58 0:00 [perl] <defunct>
bananapi 25924 0.0 0.0 3612 864 pts/0 S+ 13:02 0:00 grep --color=auto fhem
und jetzt das list von einem PRESENCE Device:
Internals:
ADDRESS 192.168.171.109
CHANGED
DEF lan-ping 192.168.171.109 300 300
MODE lan-ping
NAME PC_Kopierer
NR 1467
STATE present
TIMEOUT_NORMAL 300
TIMEOUT_PRESENT 300
TYPE PRESENCE
Readings:
2016-05-12 12:58:45 presence present
2016-05-12 12:58:45 state present
Helper:
DISABLED 0
Running_pid:
abortFn PRESENCE_ProcessAbortedScan
finishFn PRESENCE_ProcessLocalScan
fn PRESENCE_DoLocalPingScan
pid 25950
Abortarg:
Attributes:
disable 0
event-on-change-reading .*
room _PC
Gruß
Ingo
Kannst Du bitte einen neuen Thread aufmachen, ich glaube, wir missbrauchen gerade diesen ...
Auf jedem Falle werden bei Dir die extern gestarteten "pings" nicht ordentlich beendet ...
ähm... neuer Thread - ja, aber später...
und die Ping Prozesse werden nur währen des FHEM startvorgangs nicht richtig bendet. Ansonsten bleibt der LOG bei mir leer...
P.S. hast Du nur diesen einen, oder mehrere lan-pings?
Ist das gerät i der Zeit "da", also anpingbar?
mehrere Pings >10 teils anwesend und teils nicht... ob die Geräte die nicht anwesend sind die Timeouts auslösen kann ich nicht sagen, da ich ncht sehen kann zu welchem Ping der Timeout gehört
Zitat von: automatisierer am 12 Mai 2016, 14:10:14
mehrere Pings >10 teils anwesend und teils nicht... ob die Geräte die nicht anwesend sind die Timeouts auslösen kann ich nicht sagen, da ich ncht sehen kann zu welchem Ping der Timeout gehört
@automatisierer: Ich muss jetzt nochmal nachfragen, hast Du ausser den Zombies eigentlich auch das update-Problem? Ansonsten würde ich vorschlagen wirklich damit einen anderen Thread aufzumachen, ansonsten verwirrt das heir nur, denn es ist schwer die verschiedenen Statusinfos auseinanderzuhalten (welche Plattform, Linux/perl-version, Prozesslisten etc).
mein system läuft so wie es soll - kein updateproblem.
gibt nen neuen thread...
Gruß
Ingo
Danke
@Steffen: Melde dich wenn das Problem auch nach dem Neueinrichten wieder kommt.