Morgen,
gerade 2 x hintereinander passiert:
Habe gestern, da keine Reaktion mehr (Warum weiß ich auch nicht) auf Aktionen möglich war, die Gunst der Stunde genutzt, und ALLES neu von der ETS5 eingelesen, beschriftet und sortiert…
Beim „Aufräumen“ des Archives (löschen der nicht mehr vorhanden Assos.) stürzt das komplette IPS ab. Und startet auch nicht mehr neu!
Muss es über die Kommandozeile neu starten.
Bitte um Hilfe.
lg
IP-Symcon 5.0, Raspberry Pi, 13.12.2018, 93cb63bbeb2
Ich habe das gleiche Problem. Auch IP-Symcon 5.0 und Raspberry.
Bei Docker auch.
Ich meine was gehört zu haben das man da dran ist ?!
Könnt ihr das Problem auch nachstellen, wenn ihr den Debugger startet? Wir haben zu dem Problem schon einmal ein Thema gehabt, ob bisher war das Problem bei uns nicht nachstellbar 
paresy
Was muss ich machen, um das Aufräumen im Archive zu debuggen? Hast du noch Hinweise, welche Infos du zum Nachvollziehen noch brauchst oder spezielle Abläufe?
(gdb) bt
#0 0x00ca3190 in std::_Hashtable<int, std::pair<int const, IPSAggregationVariableEx>, std::allocator< std::pair<int const, IPSAggregationVariableEx> >, std::__detail::_Select1st, std::equal_to<int>, std:: hash<int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Pri me_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::erase(std::__detail::_Node_c onst_iterator<std::pair<int const, IPSAggregationVariableEx>, false, false>) ()
#1 0x00c96c88 in ArchiveControl::ApplyChanges() ()
#2 0x00ca1044 in ArchiveControl::DeleteVariableData(unsigned short, long, long) ()
#3 0x00a072dc in Glue::RPC::AC_DeleteVariableData(IIPSKernelEx*, rapidjson::GenericValue<rapidjson::U TF8<char>, rapidjson::CrtAllocator> const&, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson:: CrtAllocator>&, rapidjson::CrtAllocator&) ()
#4 0x00db1394 in IPSDataServer::InvokeMethod(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator> const &, rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::CrtAllocator>&, rapidjson::CrtAllocator&) ()
#5 0x00dd9070 in void IPSDataServer::HandleRPCRequest<asio::basic_stream_socket<asio::ip::tcp> >(std: :ostream&, std::shared_ptr<SimpleWeb::Request<asio::basic_stream_socket<asio::ip::tcp> > >) ()
#6 0x00ddb9ec in std::_Function_handler<void (std::ostream&, std::shared_ptr<SimpleWeb::Request<asio: :basic_stream_socket<asio::ip::tcp> > >), void IPSDataServer::AssignServerHandler<asio::basic_stream_s ocket<asio::ip::tcp> >(std::shared_ptr<SimpleWeb::Server<asio::basic_stream_socket<asio::ip::tcp> > >) ::{lambda(std::ostream&, std::shared_ptr<SimpleWeb::Request<asio::basic_stream_socket<asio::ip::tcp> > >)#2}>::_M_invoke(std::_Any_data const&, std::ostream&, std::shared_ptr<SimpleWeb::Request<asio::basi c_stream_socket<asio::ip::tcp> > >&&) ()
#7 0x007ae2e8 in SimpleWeb::ServerBase<asio::basic_stream_socket<asio::ip::tcp> >::write_response(std ::shared_ptr<asio::basic_stream_socket<asio::ip::tcp> >, std::shared_ptr<SimpleWeb::Request<asio::basi c_stream_socket<asio::ip::tcp> > >, std::function<void (std::ostream&, std::shared_ptr<SimpleWeb::Requ est<asio::basic_stream_socket<asio::ip::tcp> > >)>) ()
#8 0x007ae98c in SimpleWeb::ServerBase<asio::basic_stream_socket<asio::ip::tcp> >::match_resource(std ::shared_ptr<asio::basic_stream_socket<asio::ip::tcp> >, std::shared_ptr<SimpleWeb::Request<asio::basi c_stream_socket<asio::ip::tcp> > >) ()
#9 0x007aed9c in asio::detail::read_dynbuf_op<asio::basic_stream_socket<asio::ip::tcp>, asio::basic_s treambuf_ref<std::allocator<char> >, asio::detail::transfer_exactly_t, SimpleWeb::ServerBase<asio::bas ic_stream_socket<asio::ip::tcp> >::read_request_and_content(std::shared_ptr<asio::basic_stream_socket< asio::ip::tcp> >)::{lambda(std::error_code const&, unsigned int)#1}::operator()(std::error_code const& , unsigned int) const::{lambda(std::error_code const&, unsigned int)#3}>::operator()(std::error_code c onst&, unsigned int, int) ()
#10 0x007aefd0 in asio::detail::reactive_socket_recv_op<asio::mutable_buffers_1, asio::detail::read_dy nbuf_op<asio::basic_stream_socket<asio::ip::tcp>, asio::basic_streambuf_ref<std::allocator<char> >, as io::detail::transfer_exactly_t, SimpleWeb::ServerBase<asio::basic_stream_socket<asio::ip::tcp> >::read _request_and_content(std::shared_ptr<asio::basic_stream_socket<asio::ip::tcp> >)::{lambda(std::error_c ode const&, unsigned int)#1}::operator()(std::error_code const&, unsigned int) const::{lambda(std::err or_code const&, unsigned int)#3}> >::do_complete(void*, asio::detail::scheduler_operation*, std::error _code const&, unsigned int) ()
#11 0x00dabf98 in std::thread::_State_impl<std::_Bind_simple<IPSDataServer::MessageSink(IPSMessage con st&)::{lambda()#1} ()> >::_M_run() ()
#12 0x766cd9dc in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#13 0x76f7efc4 in start_thread (arg=0x65df32a0) at pthread_create.c:458
Kann das sein, das IPS jetzt nicht mehr automatisch startet?
Und jetzt gibt es einen neuen Fehler beim Aufräumen:
Das bekomme ich unter Docker auch. Im Terminal vom Container ist hierzu nichts zu sehen. Der Container stürzt einfach ab (und startet neu).
Ist das vielleicht einfach nur ein „file not foud“ 
Habt ihr die Möglichkeit zu prüfen, ob der Fehler auch auf der 5.1 passiert? Wir hatten an der Stelle in paar Dinge umgebaut - vielleicht löst dies das Problem.
paresy
Hab schnell die 5.1 Testing installiert und danach aufgeräumt. Es kam zwar anfangs eine Fehlermeldung, dass eine csv nicht gefunden werden konnte. Bei einem zweiten Versuch war das Aufräumen dann erfolgreich und IPS ist auch nicht mehr abgestürzt.
Auch das Reaggregieren lief ohne Absturz durch.
