Scene Exiting: LuaUPnP Terminated with Exit Code: 137

All,
We have been developing a power monitoring utility on the VERA platform for quite some time now.
And we have been having a consistent problem all this time.
The LuaUPNP Virtual Machine shuts down every now and then (atleast once every day) when we run our scene code.

We are using a Build version: 1.1.1245
the code uses the following calls to the LUUP Engine:

luup.variable_get
luup.call_timer
luup.call_action
luup.log
luup.inet.wget
luup.variable_set

We went through the following forum post : http://forum.micasaverde.com/index.php?topic=8737.0 - which suggests that if the Scene code runs for more than 30 seconds - the uPNP VM tends to crash…
This is how our code executes:
step 1> It runs for around 2 seconds
step 2> Sleeps for around 10 seconds (after invoking call_timer)
step 3> Wakes up back based on call_timer’s callback operation and goes back to step 1

So, the code never runs for > 30 seconds continuously.

We need your opinions on approaching this issue. Attaching the log files here. (i have renamed the *.gz files as *.txt files. Please rename the attached files to .gz on download)

Same here.
Just installed the ERGY plugin… unit becomes unusable due to restarts!!!
MCV does not seem to know. Removed the plugin and everything is fine.

Unbelievable!!!

Flo

[quote=“SrivatsanMohan, post:1, topic:170588”]All,
We have been developing a power monitoring utility on the VERA platform for quite some time now.
And we have been having a consistent problem all this time.
The LuaUPNP Virtual Machine shuts down every now and then (atleast once every day) when we run our scene code.

We are using a Build version: 1.1.1245
the code uses the following calls to the LUUP Engine:

luup.variable_get
luup.call_timer
luup.call_action
luup.log
luup.inet.wget
luup.variable_set

We went through the following forum post : http://forum.micasaverde.com/index.php?topic=8737.0 - which suggests that if the Scene code runs for more than 30 seconds - the uPNP VM tends to crash…
This is how our code executes:
step 1> It runs for around 2 seconds
step 2> Sleeps for around 10 seconds (after invoking call_timer)
step 3> Wakes up back based on call_timer’s callback operation and goes back to step 1

So, the code never runs for > 30 seconds continuously.

We need your opinions on approaching this issue. Attaching the log files here. (i have renamed the *.gz files as *.txt files. Please rename the attached files to .gz on download)[/quote]

Hey SrivatsanMohan,

I am suffering for the same, LuaUPnP Terminated with Exit Code: 137, did you find any solution to that?

Regards.

Hi all. I 'm having lot of luup restart. I have spent several hours to understand why, and I have also disinstalled some plugins. But the problem persists. Though this is not the correct tread, I attach the part of log that preceeds the restart. I am not able to find out the problem.
Here the log.
I don’t know if I’m running out of memory, I have a memory stick inserted to save log files to USB, I have two Smart Virtual Thermostat and my network seems to run correctly.
May be a coincidence but the problems arose after VeraAlerts self updated a couple of days ago. Now I removed VeraAlerts Plugin, in the doubt…
Grazie e ciao

I would power cycle your vera … (This is different then hitting the reload button on the Dashboard).
The indications look like things are getting stuck. Not sure if it’s out of memory … Or network connection is taking to much time. In the latter, if you get to many network requests queued up … than Vera will Restart because something is wrong and it can’t keep up with incoming request.

Do you have a Static IP for your Vera ?
Do you have a Static DHCP reservation for your Vera ?
I would recommend one of the above if not, I prefer the latter.

How Many Z-Wave devices ?
What kind and how many of each Plugins ?
Do you have the Energy settings enabled ?

I’m having the same issue. Vera Alerts stopped, a few days ago.

I’ve removed vera alerts via URL delete but see this in the logs JobHandler_LuaUPnP::HandleActionRequest can’t handle service: urn:richardgreen:serviceId:VeraAlert1 <0x2b741680>

I also see ZW_Send_Data node 4 NO ROUTE (nil) for a few different nodes

I have a Static IP via DHCP reservation
Power cycle -was done last night
I have about 12 zwave devices
plug-ins thermostat opensprinkler, 6 foscams, datamine, weatherundergound, DirecTV Media Control Plugin, Day Night, PLEG
energy settings enabled Yes
last vera alert 12/4 about 12 am MST

Thanks Jeff

You will get the messages about can’t handle service … because you removed the Vera Alerts Plugin without disconnecting the Notifications from plugin first. This will not hurt anything … just adds noise yo your logs.

I do see you have the Energy plugin installed … I have seen plenty of weird problems related to this. If you still have problems you might want to disable it.

I uninstalled a few other unused plugins like
virtual switch, virtual theromostat, countdown timer, and ENERGY
reinstalled vera alerts reconfigured

everything seems stable now…

Thanks for your guidance and all your great work!!

Jeff

I too have uninstalled ERGY and another unused plugin. But a question: when PLTS is ON it begin to countdown from example 10:00 to 00:00 every second, and every second it display a msg like these?
However now on the experience of jeffreyrgibbs, I’ll reinstall VeraAlerts and its parameters. Thank you

12/09/13 21:00:10.003 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:22 now: 03:21 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:11.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:21 now: 03:20 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:12.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:20 now: 03:19 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:13.003 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:19 now: 03:18 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:14.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:18 now: 03:17 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:15.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:17 now: 03:16 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:16.003 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:16 now: 03:15 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:17.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:15 now: 03:14 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:18.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:14 now: 03:13 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:19.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:13 now: 03:12 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:20.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:12 now: 03:11 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:21.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:11 now: 03:10 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:22.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:10 now: 03:09 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:23.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:09 now: 03:08 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d34b680>
06 12/09/13 21:00:24.101 Device_Variable::m_szValue_set device: 52 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: TimeRemaining was: 03:08 now: 03:07

My Vera has been extremely unstable and I suspect Vera Alert is the problem.
I uninstalled the old version, which didn’t have the register tab, because my system was unstable.
After I installed the new version, the LuaPnP doesn’t start always. Even if it starts, it is extremely unstable !

And why is is so slow on my Android device now?

What type of Vera ?
Hope many Devices and of what types (How many Z-Wave … How Many PLEG ? How Many Countdown … ) ?
Do you have a USB stick installed and enabled for storing the Log files ?
Do you know how much free memory you have ?

-What type of Vera ? Vera 3
-How many Devices and of what types (How many Z-Wave … How Many PLEG ? How Many Countdown … ) ? About 170, which includes virtual devices, about 70 X10 and 30 or so Zwave
-Do you have a USB stick installed and enabled for storing the Log files ? Yes, USB stick installed
-Do you know how much free memory you have ? Normally 20% free. Almost 53% occupied by LuaPnP. But LuaPnP bloats to 150% and system becomes non responsive. Sometimes LuaPnP doesn’t start with 317 error code.
-Why am I suspecting VeraAlert? Because it is the only change to my system recently. I keep all auto updates off, because I don’t want Vera to restart. The log get full of error messages related to the event server as well.

I am guessing. I don’t have a concrete evidence yet.

Here is the Log and TOP, when LuaPnP does not restart.

Any device that has a controlling device … is pretty cheap (i.e. all of the Z-Wave devices have a controlling device of the internal ZWave device.)
See the 1st entry in the Advanced tab.

Also the Sensor and Partition devices from an Alarm System are controlled by the Alarm plugin … So they are pretty cheap on memory.

So how may of each type of PLUGIN is important … that fact that you are hitting 150% of memory is why you have stability issues …
The plugins are allocating more memory than you have … when some event comes in and the plugins actually need to use that memory … you will die.

There is some double counting in the memory number … So you might still be stable up to around 110% … but if you giver her more than that … she will blow :frowning:
[hr]
I did look over the Vera Alerts code … and I have some cases where when you exceed the license limits, there is a bug … I have some early returns that do not have the proper return arguments for some functions that are run as Vera Jobs. That may eventually cause Vera to restart.

Thanks for your response.

I have only 6 plugins. But I didn’t have this issue before.

What do I look for in the log to find the root cause of the problem?