HAllo zusammen,
ich habe ein echt doofes Problem,
in unregelmäßigen Abständen aber ca 2-3 mal die Woche hängt sich Symcon einfach auf.
Webfrontend und console sind nicht mehr zu erreichen.
Auch Scripte etc. laufen nicht mehr.
Also Symcon scheint tot zu sein.
Der Dienst läuft allerdings noch (läuft bei mir auf RPI).
Das einzige was Hilft ist ein manueller Dienstneustart über ssh.
Das ist natürlich doof.
Besonders wenn Mann unterwegs ist und Frau zu hause genrvt ist weil was nicht geht…
Wie kann man das analysieren?
Hat jemand ähnliche Probleme?
HILFE!!! wäre schon ziemlich wichtig.
Gibt mehrere Möglichkeiten. Fürs erste könntest du mal ins Logfile schauen, ob es dort ein Muster gibt, wann der Absturz passiert. Oder ob dort irgendwelche Fehlermeldungen sind?
Jedoch wird bei dir keine Exception passieren, sondern der Prozess stehen bleiben. Dann bitte CTRL+C drücken, um in der GDB Eingabeaufforderung zu landen und „info threads“ eintippen. Die Ausgabe (ggf mehrere Seiten) würde mich Interessieren. Ggf. klemmt bei dir etwas… !?
ok fantastisch, sitze gerade in einem Linux-Kurs und habe jetzt Zeit und Know How sammeln können
debugging über gdb läuft.
Screen kenne ich jetzt auch
ich warte auf den nächsten Crash und dann schauen wir mal :-D:-D
Das verwundert mich etwas - dein Verhalten beschreibt ja eher einen Stillstand. Ein segfault ist aber ein Absturz, welcher den Prozess komplett verschwinden lässt. Magst du das Debugging einfach noch einmal starten?
Dies ist eine Notlösung aber was soll man sonst machen wenn ein System das Seit zwei Jahren Stabil lief und nun seit dem Update auf die neue Version nicht mehr…
vielen Dank für dein Feedback. Um das Problem finden zu können, sind wir leider auf eure Hilfe angewiesen, da dieses Problem bisher nicht auf unseren Systemen aufgetreten ist. Ich würde mich also freuen, wenn du uns ggf. auch mit einem Backtrace oder der Auflistung der laufenden Threads aushelfen könntest.
System 1: Raspi 3 mit Jessie und der letzten Symcon 4.3er Version dafür -->
Homematic über Yahm, MQTT über mosquitto am PI und Schnittstellen zu ETA SH20, Logitech Mediaserver, Harmony Hub, Unifi.
System 2: KVM Ubuntu 16.04 auch mit der letzten 4.3er Symcon Version -->
Siemens S7 (nur lesen) und MQTT über den mosquitto broker am selben Server sowie Unifi.
Hier Lese ich aus der S7 in sehr kurzen Abständen (200ms) Werte damit ich auch die Spitzen einigermaßen erfassen kann, da Siemens nichts besseres als Polling kann.
Das für mich Eigenartige ist das beide Systeme die keine Verbindung haben innerhalb weniger Wochen die selben Ausfall Erscheinungen hatten, vorher aber über ein Jahr ohne Funktionierten und die einzige Änderung war die neuere Version von Symcon.
Auch kann ich es nicht verstehen wie ihr solche Fehler nicht nachstellen könnt, wie auch beim exec Problem das durch die 4.3er aufgetreten aber nicht von euch gelöst wurde!
12:05:31 | 28821 | Serial Port | Applied settings
12:05:31 | 28821 | Serial Port | Closing port...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x5dfff430 (LWP 12887)]
0x0067dbec in boost::asio::detail::epoll_reactor::start_op(int, int, boost::asio::detail::epoll_reactor::descriptor_state*&, boost::asio::detail::reactor_op*, bool, bool) ()
(gdb) bt
#0 0x0067dbec in boost::asio::detail::epoll_reactor::start_op(int, int, boost::asio::detail::epoll_reactor::descriptor_state*&, boost::asio::detail::reactor_op*, bool, bool) ()
#1 0x0068c3d8 in IOSerialPort::startWriting(std::shared_ptr<std::string>) ()
#2 0x0068e20c in boost::asio::detail::completion_handler<boost::_bi::bind_t<void, boost::_mfi::mf1<void, IOSerialPort, std::shared_ptr<std::string> >, boost::_bi::list2<boost::_bi::value<IOSerialPort*>, boost::_bi::value<std::shared_ptr<std::string> > > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned int) ()
#3 0x00366620 in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
#4 0x006878a4 in std::thread::_Impl<std::_Bind_simple<IOSerialPort::Connect()::{lambda()#1} ()> >::_M_run() ()
#5 0x768e5348 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
das wäre schade