Wenn mein PI mit aktueller version von IPS 4.0 zirka 12 Stunden läuft dann läst sich der Dienst über
sudo service symcon stop
nicht mehr stoppen
ich denke ich weiß auch an was es liegt siehe screenshot
es bleiben immer die selben Module hängen liegt das jetzt noch an IPS oder an den Modulen
und kann mann da was ändern ?
Gruß
Bruno
Vermutlich liegt das an einem Fehler in der Sys_GetURLContent Funktion, die manchmal stecken bleibt. Passend dazu auch der Fehler: Image-Grabber
paresy
Ok dann muß ich momentan damit Leben
Wird das noch gefixt ??
Gruß
Bruno
Klar wird das gefixt. Aber bis dahin noch etwas Geduld. 
paresy
Öh… der hängende HM_ReadSystemvariables nutzt nur cURL nicht Sys_GetURLContent.
Michael
@Michael: Dann müssen wir uns da ggf. auch noch mal ansehen. Passiert das bei dir auch?
Bugfix dafür ist im nächsten Update drin!
paresy
Das ist super
Da das eigentliche Problem das ist das ich den Dienst nach etwa einem tag Killen muss da kein Script mehr ausgeführt wird
Und noch ne dumme frage
IPS weiß ja anscheinend das der Tread hängt kann mann denn nicht einfach nach einer gewissen Zeit wieder freigeben :rolleyes:
Gruß
Bruno
Ne, das geht leider nicht so „einfach“
paresy
Hallo Michael, Parsey,
ich habe auch das Problem das sich symcon nach einigen Minuten / Stunden nicht mehr normal beenden lässt und ich den Dienst killen muss.
Auch ich verwende die Homematic Anbindung und habe soeben den folgenden Screenprint erstellt:
Danke für eure Tolle Unterstützung / Arbeit!
Paul
PS: dies hier ist das log meines Watchdogs der symcon neu startet…
![IP-Symcon Management Console [home]_063.png](https://community.symcon.de/uploads/default/original/2X/1/1de91ad1dbb0ca878efb093edfe2209cf3e35336.png)
Di 9. Feb 22:17:01 CET 2016 symcon watchdog startet service! Too many scripts at once. Dropping execution...
Do 11. Feb 19:35:25 CET 2016 symcon watchdog startet service! Scripts können nicht gestartet, sobald Abschaltung eingeleitet wurde...
Fr 12. Feb 17:45:01 CET 2016 symcon watchdog startet service! Too many scripts at once. Dropping execution...
Ich hab’ die Erweiterung hier mal Installiert und lasse die mal laufen bis der Fehler hoffentlich auftritt
paresy
Das ist gut… ich komme gerade zu gar nix. Meine ganzen Test-4er sind alle noch vor RC1 und laufen nur bei Bedarf.
Michael
Nach gestrigem Update immer noch gleiches Problem :mad:
Es sind immer nur TimerEvents
Gruß
Bruno
Da ist leider nichts was ich machen kann. Es ist laut Recherche ein Fehler im Linux Kernel. Ihr könnt also versuchen euer System noch einmal mit z.B. rpi-update / apt-get upgrade zu aktualisieren. Falls das nicht hilft, heißt es leider warten bis Raspbian fixes für das Problem bringt.
Betroffen sind alle Netzwerk Befehle… wie cURL, Sys_Ping, Sys_GetURLContent, file_get_contents.
Als Referenz:
Steven Schlansker - Indefinite hang in getaddrinfo / check_pf / make_request
12926 – getaddrinfo()/make_request() may spin forever
LKML: Guenter Roeck: Re: Glibc recvmsg from kernel netlink socket hangs forever
Glibc recvmsg from kernel netlink socket hangs forever | Linux | Kernel
Bug 1209433 – Deadlock in __check_pf()
Relevante Backtraces von IP-Symcon:
#0 0x7691b6b0 in recvmsg () at ../sysdeps/unix/syscall-template.S:82
#1 0x7693c7d8 in make_request (fd=40, pid=8379, seen_ipv4=0x6e5fafb6,
seen_ipv6=0x6e5fafb7, in6ai=0x6e5fafa0, in6ailen=0x6e5fafa4)
at ../sysdeps/unix/sysv/linux/check_pf.c:119
#2 0x7693cc28 in __check_pf (seen_ipv4=0x6e5fafb6, seen_ipv6=0x6e5fafb7,
in6ai=0x6e5fafa0, in6ailen=0x6e5fafa4)
at ../sysdeps/unix/sysv/linux/check_pf.c:270
#3 0x768f8160 in __GI_getaddrinfo (name=0x613573c0 "10.0.1.140",
service=<optimized out>, hints=0x6e5fb018, pai=0x6e5fafec)
at ../sysdeps/posix/getaddrinfo.c:2389
#4 0x76ce681c in ?? () from /usr/lib/arm-linux-gnueabihf/libcurl.so.4
--------------------------
#0 0x7691b6b0 in recvmsg () at ../sysdeps/unix/syscall-template.S:82
#1 0x7693c7d8 in make_request (fd=38, pid=8379, seen_ipv4=0x6edfa4be,
seen_ipv6=0x6edfa4bf, in6ai=0x6edfa4a8, in6ailen=0x6edfa4ac)
at ../sysdeps/unix/sysv/linux/check_pf.c:119
#2 0x7693cc28 in __check_pf (seen_ipv4=0x6edfa4be, seen_ipv6=0x6edfa4bf,
in6ai=0x6edfa4a8, in6ailen=0x6edfa4ac)
at ../sysdeps/unix/sysv/linux/check_pf.c:270
#3 0x768f8160 in __GI_getaddrinfo (name=0x3ba15b0 "10.0.1.111",
service=<optimized out>, hints=0x6edfa4f8, pai=0x6edfa4f4)
at ../sysdeps/posix/getaddrinfo.c:2389
#4 0x00bf9ecc in php_network_getaddresses ()
#5 0x00bfa7a4 in php_network_connect_socket_to_host ()
#6 0x008f5728 in php_tcp_sockop_set_option ()
#7 0x00a23b94 in php_openssl_sockop_set_option ()
at /home/pi/kernelcpp/res/php-5.6.17/ext/openssl/xp_ssl.c:2240
#8 0x008ee1c4 in _php_stream_set_option ()
at /home/pi/kernelcpp/res/php-5.6.17/main/streams/streams.c:1357
#9 0x008f3fc0 in php_stream_xport_connect ()
#10 0x008f437c in _php_stream_xport_create ()
#11 0x00ba57a0 in php_stream_url_wrap_http_ex ()
#12 0x00ba86d8 in php_stream_url_wrap_http ()
#13 0x008ef58c in _php_stream_open_wrapper_ex ()
--------------------------------------
#0 0x7691b6b0 in recvmsg () at ../sysdeps/unix/syscall-template.S:82
#1 0x7693c7d8 in make_request (fd=39, pid=8379, seen_ipv4=0x70dfb606,
seen_ipv6=0x70dfb607, in6ai=0x70dfb5f0, in6ailen=0x70dfb5f4)
at ../sysdeps/unix/sysv/linux/check_pf.c:119
#2 0x7693cc28 in __check_pf (seen_ipv4=0x70dfb606, seen_ipv6=0x70dfb607,
in6ai=0x70dfb5f0, in6ailen=0x70dfb5f4)
at ../sysdeps/unix/sysv/linux/check_pf.c:270
#3 0x768f8160 in __GI_getaddrinfo (name=0x6633f754 "10.0.1.111",
service=<optimized out>, hints=0x76961764, pai=0x70dfb640)
at ../sysdeps/posix/getaddrinfo.c:2389
#4 0x005c9214 in Glue::PHPExtension::Sys_Ping(int, _zval_struct*, _zval_struct**, _zval_struct*, int, void***) ()
#5 0x009df98c in zend_do_fcall_common_helper_SPEC ()
at /home/pi/kernelcpp/res/php-5.6.17/Zend/zend_vm_execute.h:558
#6 0x00969fd8 in execute_ex ()
at /home/pi/kernelcpp/res/php-5.6.17/Zend/zend_vm_execute.h:363
#7 0x009dd600 in zend_execute ()
at /home/pi/kernelcpp/res/php-5.6.17/Zend/zend_vm_execute.h:388
#8 0x009378b4 in zend_execute_scripts ()
#9 0x008d6c20 in php_execute_script ()
#10 0x007885a8 in IPSScriptEngine::RunScriptThread(IPSScriptThreadEx&) ()
#11 0x76a69848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#12 0x76a69848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
paresy
Na TOOL :eek:
OK dann zurück auf windows
Gruß
Bruno
Hi, hatte das Problem auch. Bei mir waren es immer nur die Scripts die meine Funk-Steckdosen schalten.
Nach Infos von Parsey ist aus dem Script:
shell_exec("sudo pilight-send -p elro_800_switch -s 27 -u 1 -t");
Das hier geworden:
exec("sudo pilight-send -p elro_800_switch -s 27 -u 1 -t > /dev/null &");
Und es läuft jetzt ohne ein Hängerchen. Das dies bei anderen Scripten nicht so einfach möglich ist, kann ich mir vorstellen, aber vll. hilft es ja dem ein oder andrem.
PS. Warum sehe ich bei allen Screenshots hier immer welche mit mehr als 10 Threads?! Meiner geht nur bis 10! Warum??:p:D
PSS. Auch mal hier nachgefragt:
Kann man vll. irgendwie eine Instanz anlegen die mir die hängenden Threads hochzählt?
Das man z.B. bei Werten von 5,6,7, … eine PUSH/eMail versenden kann, bevor sich die IPS selber ausbremst?
Du bist ne Wucht! Merci! 
Ersten Berichten zufolge löst sich das Problem mit einem „rpi-update“ wodurch der Kernel auf mindestens folgende Version aktualisiert wird:
Linux raspberrypi 4.1.18
paresy