IPS auf RPi stürzt regelmäßig ab

IP-Symcon
1

Hallo Community,

habe gestern IPS auf dem RPi installiert, und bin gerade dabei mich etwas einzulernen. Mir ist aufgefallen dass bei Benutzung der Android-App IPS regelmäßig abstürzt.
Ich verwende das KNX/EIB Modul um meine Gruppenadressen zu schalten und die Temperatur der Raumthermostate auszulesen. Der IPS Daemon lief jetzt über Nacht problemlos und aktualisiert auch schön die Temperaturwerte, doch sobald ich anfange das Licht ein- und auszuschalten verabschiedet sich der IPS Prozess.
Im Logfile steht auch nichts aufregendes, gibt es vielleicht eine andere Debugging-Methode? :confused:
Möchte ungern auf einen Windows-Server ausweichen :cool:

mfg
xeron

2

Es gibt leider bisher noch ein bekanntes Problem mit dem UDP Socket (welcher für KNX auch genutzt wird). Sobald anscheinend viele Rückmeldungen vom Bus kommen, kommt es manchmal zu einem Absturz.

paresy

3

Das ist natürlich ärgerlich. Habe mein Problem jetzt doch einigermaßen in den Griff bekommen.
Ich verwende eine USB Schnittstelle um auf mein KNX zuzugreifen, dieses hängt direkt am RPi. Auf dem Pi läuft der eibd, der als Schnittstelle zwischen IPS (läuft auf dem selben Pi) und dem Bus fungiert.
Ich habe bemerkt dass der eibd immer die ganze CPU auslastet, nachdem man einen Befehl auf den Bus sendet. Nachdem ich jetzt den pthsem mit einem Hack neu kompiliert habe, bleibt die CPU-Auslastung im überschaubaren Bereich, und IPS scheint auch nicht mehr abzustürzen. :smiley:

Post #10: EIBD auf Arm 100% CPU Last - KNX-User-Forum

Mal schauen ob das Problem trotzdem nochmal auftritt, ich werde auf jeden Fall noch einen Cronjob einbauen der nachsieht ob IPS noch läuft, und es evtl. startet.

4

Moin xeron,
wie hast du denn die IPS Anbindung mit dem eibd erstellt?
Gruss,
Peter

5

Hi Peter,

der eibd verhält sich wie jede x-beliebige Netzwerkschnittstelle für KNX. Das heißt er wartet auf Port 3671 UDP und 6720 TCP auf eingehende Pakete (im Tunneling- und Routingmodus).
Im IPS habe ich dann mit dem KNX/EIB Konfigurator einen UDP Socket erstellt, welcher sich zum eibd verbindet und die Reads/Writes weiterreicht.

mfg
Mark

6

Nachdem ich heute mehrere Umstellungen im ETS vorgenommen habe, ist IPS wieder einige male abgestürzt (vor allem während dem Programmieren der Geräte).
Ist eine Lösung für das Stabilitätsproblem mit dem Linux-UDPsocket in Sicht? :frowning:

7

Schmiert IPS sonst nicht ab bei dir? Bei mir läuft es keine 5 Stunden mit KNX aktiviert.
Gruß, Peter

8

Solange ich es nicht überfordere scheint es seit dem pthsem-Hack mehr oder weniger stabil zu laufen.
Vielleicht hilft den Entwicklern der Fakt dass es bei mir mit 100% CPU-Auslastung kontinuierlich abgestürzt ist, bei der Behebung des Problems weiter.

Edit: hab heute ein wenig rumgespielt, neue Variablen und Scripte angelegt, IPS stürzt jetzt auch ohne ersichtlichen Grund ab :wink: Im Logfile steht nichts was auf den Crash hinweist

9

So… hier mal mein gdb-log nachdem mein IPS mit KNX-Instanz nach ca. 2 Stunden wieder abgeschmiert ist. Ich hoffe es hilft weiter?!

Gruß,
Peter


(gdb) bt
#0  0x0013b3e4 in boost::asio::detail::reactive_socket_recvfrom_op_base<boost::asio::mutable_buffers_1, boost::asio::ip::basic_endpoint<boost::asio::ip::udp> >::do_perform(boost::asio::detail::reactor_op*) ()
#1  0x0002b518 in boost::asio::detail::epoll_reactor::descriptor_state::perform_io(unsigned int) ()
#2  0x0002b63c in boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned int) ()
#3  0x0002c540 in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
#4  0x0011a9d0 in boost::asio::io_service::run() ()
#5  0x000f1c14 in std::thread::_Impl<std::_Bind_simple<boost::_bi::bind_t<unsigned int, boost::_mfi::mf0<unsigned int, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > > ()> >::_M_run() ()
#6  0x76f78848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#7  0x76f78848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
10

Und gleich nochmal ein gdb-log hinter her…

(gdb) bt
#0  0x0013b3e4 in boost::asio::detail::reactive_socket_recvfrom_op_base<boost::asio::mutable_buffers_1, boost::asio::ip::basic_endpoint<boost::asio::ip::udp> >::do_perform(boost::asio::detail::reactor_op*) ()
#1  0x0002b518 in boost::asio::detail::epoll_reactor::descriptor_state::perform_io(unsigned int) ()
#2  0x0002b63c in boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned int) ()
#3  0x0002c540 in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
#4  0x0011a9d0 in boost::asio::io_service::run() ()
#5  0x000f1c14 in std::thread::_Impl<std::_Bind_simple<boost::_bi::bind_t<unsigned int, boost::_mfi::mf0<unsigned int, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > > ()> >::_M_run() ()
#6  0x76f78848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#7  0x76f78848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)