error message ?NetowrkMonitor is stuk? is generated by the Reactor plugin

Plugins & Plugin Development Reactor
1

Greetings,
I’ve been tracking down an issue with my controller continually going off and back online . Working back and forth with VERA support, ut;s been driving me nuts!

I received this log entry today from VERA advanced suport:
"I have collected the logs from the system and from what I saw, the error message ?NetowrkMonitor is stuk? is generated by the Reactor plugin, device #210. Every time the plugin run the scene ?[ ]? the LuaUPnP crashes. Please go on the settings of the device. To do this, go to Devices > Reactor > click on the small arrow button ?>?, hit ?Advanced? > Variables, scroll down till ?runscene? and correct the scene that should run or delete it. Then, hit the ?New Service? > ?Reload Engine?

This was one of the many errors he found in the log.
10 02/02/19 17:18:44.567 Device_Variable::m_szValue_set device: 210 service: urn:toggledbits-com:serviceId:Reactor variable: runscene startup: [ ] v:(nil)/NONE <0?779dd320>

I’m new to Reactor, not sure what runscene should be other than []. Any help would be appreciated.
Attached a summary, pluginstatus and reactor_config files.

Thanks for any assistance you can give.
Dave

2

[quote=“IslandMan54, post:1, topic:200555”]Greetings,
I’ve been tracking down an issue with my controller continually going off and back online . Working back and forth with VERA support, ut;s been driving me nuts!

I received this log entry today from VERA advanced suport:
"I have collected the logs from the system and from what I saw, the error message ?NetowrkMonitor is stuk? is generated by the Reactor plugin, device #210. Every time the plugin run the scene ?[ ]? the LuaUPnP crashes. Please go on the settings of the device. To do this, go to Devices > Reactor > click on the small arrow button ?>?, hit ?Advanced? > Variables, scroll down till ?runscene? and correct the scene that should run or delete it. Then, hit the ?New Service? > ?Reload Engine?

This was one of the many errors he found in the log.
10 02/02/19 17:18:44.567 Device_Variable::m_szValue_set device: 210 service: urn:toggledbits-com:serviceId:Reactor variable: runscene startup: [ ] v:(nil)/NONE <0?779dd320>

I’m new to Reactor, not sure what runscene should be other than []. Any help would be appreciated.
Attached a summary, pluginstatus and reactor_config files.

Thanks for any assistance you can give.
Dave[/quote]

Not sure what they’re on about with that determination, but no. Reactor does not produce any such message. I’m not sure how Reactor, or anything else, would ever determine if another plugin was “stuk”. It’s not something Reactor does or attempts to do, and I would not even begin to know how to do it, or what “stuck” would mean for another plugin that I didn’t write. And I sure as heck would not misspell the word. :slight_smile:

Their instructions for you to handle runscene are… a mystery. Nothing about those instructions makes sense, and in fact, pretty clearly demonstrates that whoever wrote those instructions doesn’t know what it’s used for and how it’s used.

That said, the “[]” is a perfectly valid value for the runscene variable to have. It will be at this value any time Reactor does not have a scene running, so it will write exactly this value at the end of every scene execution. When one or more scenes is running, it will contain Reactor’s progress data for those scenes.

Your summary looks fine. None of the ReactorSensors in the summary make reference to the NetworkMonitor plugin, anywhere. Nor does the plugin status or config JSON you attached, which would be authoritative. So… not sure what to think there.

3

They are trying to shift blame from the system to your plugin…

A quick check on my VeraPlus shows

root@MiOS_5XXXXXXX:~# fgrep -e 'stuck' /usr/bin/*.sh
/usr/bin/Rotate_Logs.sh:#   Check if there is any process stuck in the D state   #
/usr/bin/Rotate_Logs.sh:                log_ERROR "NM stuck"
/usr/bin/Rotate_Logs.sh:                report_message -type $ALERT_SYS_MESSAGE -severity 0 -code "nm_stuck" "NetworkMonitor is stuck"

Which clearly indicates that the error that support is blaming is generated by the system… The NetworkMonitor process is part of the Vera backend…

4

Good Morning,
I logged into my system this morning and there are no alerts.

What I did do yesterday was:
Apply the patches from Reactor 2.2 Hotfixes to my system.
Restored Reactor from a backup as I had accidentally deleted it.
Added a new USB to the system for logs, the old one had failed.

At this point, no clue what was causing the issues, will monitor and see if it comes back.
Thanks for the quick response and a great APP.

Dave

5

If you ask me. It was the defective USB stick used for logging as the message looks to be part of the rotate logs function.

Cheers Rene

6

dgb: Thanks for that info, perhaps I’ll get back to Vera about that.
(sure wish I had more smarts to dig into my system like that)

Rene: Perhaps that was the issue, but that stick was in there a long time and always showed an error, something must have triggered this, not sure what, but it appears to be fixed for the moment.

Thanks for the info, appreciate it.

7

They are trying to shift blame from the system to your plugin…[/quote]

Well, I was trying to be a bit more diplomatic, and optimistic. They have been guilty of that in the past (not specifically my plugins that I’m aware of, but others), but there are also some really troublesome plugins out there, so I’m going to stay on the side of optimistic, but guardedly so, and call it an honest mistake. If it does turn out to be a continuation of the past disrespect they’ve shown plugin developers, however, I will be bending some ears at Vera/eZLO for sure. That’s an element of the old Vera culture that needs to go.

If Sorin gets around to reading this: I recommend support do a post-mortem on this issue with the support person in question and determine how (s)he came to the conclusion, and maybe provide some constructive guidance using the hindsight now available. The conclusion was clearly way off in the weeds, and worse, contained misinformation and faulty instructions for the customer.

A quick check on my VeraPlus shows 
root@MiOS_5XXXXXXX:~# fgrep -e 'stuck' /usr/bin/*.sh
/usr/bin/Rotate_Logs.sh:#   Check if there is any process stuck in the D state   #
/usr/bin/Rotate_Logs.sh:                log_ERROR "NM stuck"
/usr/bin/Rotate_Logs.sh:                report_message -type $ALERT_SYS_MESSAGE -severity 0 -code "nm_stuck" "NetworkMonitor is stuck"

Which clearly indicates that the error that support is blaming is generated by the system… The NetworkMonitor process is part of the Vera backend…

Heh. Great catch! I had completely forgotten that NetworkMonitor is also the name of a script of theirs. That’s too funny. I had just had a conversation with another Reactor user about using amg0’s Network Monitor plugin in preference to the old Ping Sensor, so I guess I had that on the brain. But in any case, thanks for noticing this and publishing your findings. I think this really helps.

8

I think it was an honest mistake, perhaps from missing information on my part…
Response from support:
“I cannot tell you for sure what exactly happened as I did not find all the logs uploaded on the servers. I saw that the unit rebooted several times, the LuaUPnP was crashing several times, too. The ?NetworkMonitor is stuck? was generated every time Reotate_logs.sh was running.
Basically, this script should run only once per day and the only action that I could see, was from device #210, from here I deduced that these alerts could be generated by the plugin.
To be able to further investigate this, please make sure that the logs you store on the USB stick are Verbose and if the issue re-occur, please let me know the date and time when this happened so I can take a look on them.”