SDS PLC/PAC: Měření Energie & OnlineTechnology.cz
Network Monitoring System - SDS - Síťový Dohledový Systém
Nejste přihlášen. Přihlaste se, nebo se zaregistrujte.
SDS PLC/PAC: Měření Energie & OnlineTechnology.cz » SDS-MACRO (LM) » Určení neznámé příčiny restartů SDS z LOGU
Chcete-li přispívat, musíte se přihlásit nebo projít procesem registrace.
Posledních několik dnů se mi SDS Macro z neznámých příčin restartuje. V LOGU je mimo jiné kód WDG-RST, což je na WIKI popsáno jako možný problém. Je možné jednoznačněji určit zda je příčinou ztráta napájení či případný útok nebo jinak přetížené SDS?
Proti případným útokům jsem v MIKROTIKU omezil IP ze kterých je možné do SDS vstupovat. Napájení SDS je přes UPS.
Děkuji
Josef Nešvara
S tím už nějaký čas (po předposlední aktualizaci FW) bojuji také. V průměru mám restart 1x denně. Taktéž WDG-RST. Pravidelně jsem zjistil restart pár minut po načtení get_ram přes LAN. Žádnou změnu v konfiguraci ani v běžícím SW jsem nedělal. Napájení ověřeno. U SDS nemám příliš stabilní net - řešeno přes wifi/LAN repeater, ale to bylo vždy. Taktéž bych uvítal nasměrovat na možný zdroj problémů.
Můžete sem dát výpis z toho logu ?
Ztráta napájení nebude WDG-RST. Ten je v situaci kdy dojde k restartu procesoru v okamžiku, kdy by se prováděný program zacyklil tam kde nemá.
Přetížení ze strany sítě (ethernet) to nezpůsobí (zkuste si to sami, např. extrémním zatížením přes nmap), to testujeme důsledně.
Bude potřeba vysledovat, co ten reset způsobí nebo co "nakousne" běžící program tak, že za čas dojde k resetu. První dobrý postřeh je návaznost na get_ram, můžete dát více detailů ?
Z logu můžu poskytnout jen:
[183] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:1f91 WbyFW:10.08.17, WDG-RST
Nevím, jak je to u p.Nešvary, ale u mě restart často následuje pár minut poté, co se z NB/mobilu podívám na výpis aktuálních hodnot přes get_ram. (http://192.168.1.250:8081/get_ram[50]?rn=10) K restartu ovšem dojde i bez volání, takže souvislost může být náhodná.
Edit: teď jsem nahrál poslední FW z 5.1. Počkám 2 dny, jestli nastane nějaká změna.
A tato položka se tam objevuje stále nová a nová ?
Protože WbyFW je 10.8.2017 což je dost starý firmware, tak aby to nebylo jen nějaký hodně starý záznam, a důvod restartů byl pak něco jiného...
Tak to je docela zvláštní, protože poslední FW byl z 23.10.2020. Nakonec je to vidět v logu, když jsem dnes večer aktualizoval FW a je zobrazena verze 23.10.2020. Ale po boot se zobrazuje opět verze 10.08.17 Nahraný FW je 5.1.21
A ano - uvedená hláška WDG-RST je po každém restartu stejná.
[181] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:1f91 WbyFW:10.08.17, WDG-RST
[182] uptime: 172398411 UTC:1611860206 | JUMP TO BOOTLOADER FWver: 23.10.20 (B:0, T:1), HIP:192.168.1.250
[183] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:1f91 WbyFW:10.08.17, SW-RST
END
Pro komplet info bych měl doplnit, že v létě 2020 došlo k při aktualizaci FW k přerušení spojení a znovu nahrát FW se mi podařilo až na několikátý pokus. Tak jestli problém restartů nemůže souviset s nějak poškozeným bootloaderem- viz chybná verze FW v audit log.
Zdravím,
zde je několik posledních řádek z logu SDS
031] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, EXT-RST, POR-RST
[032] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, EXT-RST, POR-RST
[033] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, BOR-RST
[034] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, BOR-RST
[035] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, EXT-RST, POR-RST
[036] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, POR-RST
[037] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, EXT-RST, POR-RST
[038] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, POR-RST
[039] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, EXT-RST, POR-RST
[040] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, BOR-RST
[041] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, WDG-RST
[042] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, WDG-RST
[043] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, WDG-RST
[044] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, WDG-RST
[045] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, WDG-RST
[046] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, WDG-RST
[047] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, WDG-RST
[048] uptime: 0 UTC: 0 | SoC BOOT HIP:fa01a8c0 GW:0101a8c0 MSK:00ffffff WEB:0050 WbyFW:17.01.19, WDG-RST
O víkendu pořádně zkontroluji napájení a zaktualizuji FW, jinak nevím kde pátrat.
Dnes došlo k restartu ve 02:25
up: +0
cca: 02:25:41 29.01.2021 Zařízení zapnuto
Restarty neumím spojit se žádnou událostí.
SW-RST je v pořádku, to je záměrný reset procesoru kvůli skoku do bootloaderu, když se má instalovat nový FW.
BOR-RST je reset kvůli poruše napájení.
WDG-RST už OK není, to znamená nějaký problém.
Jak to vypadá, stále to zlobí ?
Potřebuji více informací o tom, jak je SDS využito. Ideálně mít možnost si to v co největší a nejstejnější míře replikovat u nás ve vývoji. Ideálně mi to vše zašelte na: sds (at) an-d.cz
V pátek 29.1.2021 večer jsem zkontroloval napájení z UPS včetně vypnutí napájení do UPS a vše OK, nahrál nejnovější FW a v C programu jsem zrušil posílání dat na EPORTAL, protože již používám vlastní DB.
Od té doby k výpadku nedošlo a vše se zdá OK.
SDS využívám celkem dost.
Obsazeno je 8 x S0, 2 x AD, 20 čidel teplot, PWM, v C programu běželo odesílání dat na EPORTAL (nyní již zrušeno), řízení PWM, každou minutu vyčítání dat pro vlastní DB.
Před restarty SDS jsem žádné úpravy nedělal.
Každopádně nyní zatím vše funguje.
Jinak netrpělivě čekám na SDS MACTO ST, kterým bych nahradil to současné.
Vše je zobrazeno na www.nesvara.cz a vše se projeví tak, že v položce "dnešní spotřeba" se objeví celkový stav počítadla.
Ještě Vám zašlu email.
Děkuji
Josef Nešvara
Emaily jsem dostal, budu je řešit.
První odhady ukazují na problém při komunikaci se serverem portálu, dostává se to ke mně z více různých stran... poskytovatel serveru (zaplacená firma co poskytuje webhosting) tam u sebe něco nemá v pořádku a jejich http server (který provozují na serveru který je využit pro aplikaci webu portálu) jim ani správně neodpovídá v protokolu tak jak by měl... nevím co se tam u nich teď děje, je to divné... nicméně SDS by to mělo zvládnout, budu potřebovat zkontrolovat nahraný sds-c program.
MACRO-ST domluvte se s prodejem - p. Prejda OnlineTechnology, věřím že to nebude problém, nejspíše teď vyřizuje silnou poptávku...
Díky, email s C programy jsem Vám zaslal. S panem Prejdou jsem v kontaktu. SDS MACRO ST bude k mání na přelomu února a března.
Aktuálně jedu 37hod bez restartu. Žádnou úpravu v SDS-C jsem neprováděl, takže pokud došlo k nějaké úpravě na serveru, tak u mě pozitivní změna.
Ano poskytovatel webhostingu tam snad něco spravil, ale detaily nevím (více viz p. Prejda).
K zaslaným emailům se teprve dostanu, teď jsem ještě vytížen. Budu informovat.
Předpokládám že je možné že bude potřeba zlepšit SDS-C kód aby si lépe poradil s výpadkem portálu (tedy reakce na chyby http_get komunikace) a dále budu zkoumat, proč se to SDS nelíbí a je z toho eventuální reset. To se nesmí stát ať se webový server chová jakkoliv zle.
Optimismus byl předčasný. Dnes v rozmezí 15:05 až 15:25 několik restartů. Aktuálně v 19:38 další restart, kterému předcházela chyba http get 9 - sekundární timeout (server nekomunikuje).
U mne dobrý, protože jsem shodu okolností zrušil odesílání dat na PORTAL.
Je zvláštní, že by se to netýkalo všech, takže nemůžu vyloučit problém v mém Macru - psal jsem p.Prejdovi. Co se týče portálu, také připravuji přechod na vlastní SQL - chci to spojit s novým Macrem-ST, na které také čekám.
Zkušební beta fw odeslána těm co se ozvali na sds (at) an-d.cz,
zatím není zřejmé co by bylo příčinou, ale předběžně to dávám do souvislosti s odesíláním na portál,
takže v beta je více paranoidní kód okolo této funkcionality.
Uvidíme co se tedy dozvíme až se to nasadí.
Zdravím,
včera jsem nahrál BETA verzi FW a obnovil jsem zasílání dat na PORTAL. Zatím vše OK.
Včera 5.2. jsem nahrál beta FW.
23:35:43 - sys[65]=1033 chyba - sekundární timeout (server nekomunikuje)
23:45:44 - restart
Čas 23:35 odpovídá času uploadu na energycloud. K tomu už nedošlo. Další upload proběhl až po restartu. Uvedenou chybu "9" jsem v konzoli viděl několikrát - vždy předcházela restartu.
Dnes zatím bez restartu.
U mne zatím bez restartu. Vše OK
Dnes 2 restarty po chybě 1033. 6:14 chyba, restart 6:24. Další 8:06 chyba, restart 8:16.
Zatím stále bez restartu, vše OK.
U mě restarty nahodile pokračují. Aktuálně sice jedu 37 hod v kuse, ale do pondělí byl restart několikrát denně. Vždy po timeout odpovědi ze serveru energycloud. Plus často restartu pomohl i náhled na hodnoty přes web a get_ram - odpověď přišla, ale když jsem po nějaké době přes web znovu načetl hodnoty ram, Macro bylo po restartu, který časově +- odpovídal době prvního dotazu.
U mě je hlavně problém v průběžném logování denních hodnot teplot a provozních dat TČ do ram - o které restartem přicházím. Podle nich v SDS řídím výkon TČ přes PWM a PI regulaci, což je restartem rozhozeno, protože je ztracený trend teplot - to je mrzuté. Topná sezona pomalu končí, ale další sezonu už půjdu raději cestou vlastního serveru. A Macro-ST, na které netrpělivě čekám.
Chcete-li přispívat, musíte se přihlásit nebo projít procesem registrace.
SDS PLC/PAC: Měření Energie & OnlineTechnology.cz » SDS-MACRO (LM) » Určení neznámé příčiny restartů SDS z LOGU