Help with Luup Reloads
-
@therealdb Do you think using a USB for logs would stop the memory leaks? The reloads continually happen until I manually do something about it
@pabla I’m not confident it will. I have my logs on a network share… just use sysmon plugin to watch for memory and when below 90.000 do a luup.reload via a scene.
--
On a mission to automate everything. -
@pabla I’m not confident it will. I have my logs on a network share… just use sysmon plugin to watch for memory and when below 90.000 do a luup.reload via a scene.
@therealdb I just SSH into my unit and checked the /tmp folder and I found this, is this normal? I have tons of these files which I have never seen before
Edit: I deleted all those files and more keep showing up by the minute lol! Something is definitely up
-
@therealdb I just SSH into my unit and checked the /tmp folder and I found this, is this normal? I have tons of these files which I have never seen before
Edit: I deleted all those files and more keep showing up by the minute lol! Something is definitely up
-
@therealdb I just SSH into my unit and checked the /tmp folder and I found this, is this normal? I have tons of these files which I have never seen before
Edit: I deleted all those files and more keep showing up by the minute lol! Something is definitely up
@pabla version 1.51 is on github, addressing the temp files problem specifically. It will delete file older than 3 minutes. I've it running in my own test system with no problems.
I still need to fix the duplication of programs in case of re-config, so just update the CurrentVersion variable on the master to 1.51 before updating the plug-in's files, so it will not configure it again.
A fix for "ChildrenInSameRoom" is on its way in the next release. Try it and lemme know.
-
One thing to add here, a possibility: I notice that the plugin is using the 'ip' attribute to store the IP address of the controller. I have found that this causes a lot of instability. Luup has certain automatic things that it does in the background to try to open connections when the IP is stored on that attribute. It's all part of their built-in automatic I/O for serial and IP connections, which this plugin doesn't use. But Luup will try, try and retry forever to start and maintain a connection to that IP. I believe that this is at least one source of a memory leak -- I suspect their error handling on connection failure is not completely cleaning up after itself, so the system leaks memory, and/or possible even sockets. I discovered this some years ago and switched all of my plugins to just use state variables for the IP. My systems do not restart due to memory leaks, and memory usage is generally flat.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
One thing to add here, a possibility: I notice that the plugin is using the 'ip' attribute to store the IP address of the controller. I have found that this causes a lot of instability. Luup has certain automatic things that it does in the background to try to open connections when the IP is stored on that attribute. It's all part of their built-in automatic I/O for serial and IP connections, which this plugin doesn't use. But Luup will try, try and retry forever to start and maintain a connection to that IP. I believe that this is at least one source of a memory leak -- I suspect their error handling on connection failure is not completely cleaning up after itself, so the system leaks memory, and/or possible even sockets. I discovered this some years ago and switched all of my plugins to just use state variables for the IP. My systems do not restart due to memory leaks, and memory usage is generally flat.
@toggledbits said in Help with Luup Reloads:
But Luup will try, try and retry forever to start and maintain a connection to that IP.
Yes, this is, indeed, an issue, although NOT one, I would say, for openLuup. It may well explain why Vera behaves (sort of) when you remove some plugins.
For some time, now, I had a Vera Edge running without any plugins or Z-wave devices, and, I have to say, it just runs and runs!
-
One thing to add here, a possibility: I notice that the plugin is using the 'ip' attribute to store the IP address of the controller. I have found that this causes a lot of instability. Luup has certain automatic things that it does in the background to try to open connections when the IP is stored on that attribute. It's all part of their built-in automatic I/O for serial and IP connections, which this plugin doesn't use. But Luup will try, try and retry forever to start and maintain a connection to that IP. I believe that this is at least one source of a memory leak -- I suspect their error handling on connection failure is not completely cleaning up after itself, so the system leaks memory, and/or possible even sockets. I discovered this some years ago and switched all of my plugins to just use state variables for the IP. My systems do not restart due to memory leaks, and memory usage is generally flat.
@toggledbits yep, I will change it in next build. I'm onto it as we speak. On my system I have few plug-ins, no one is using an IP and I'm still experiencing memory leaks. But I will probably just move everything to openLuup and use the Vera as a radio system.
--
On a mission to automate everything. -
@toggledbits said in Help with Luup Reloads:
But Luup will try, try and retry forever to start and maintain a connection to that IP.
Yes, this is, indeed, an issue, although NOT one, I would say, for openLuup. It may well explain why Vera behaves (sort of) when you remove some plugins.
For some time, now, I had a Vera Edge running without any plugins or Z-wave devices, and, I have to say, it just runs and runs!
@akbooer said in Help with Luup Reloads:
Yes, this is, indeed, an issue, although NOT one, I would say, for openLuup.
Sorry, did I miss that this was openLuup? Or are you just confirming that openLuup is better than real Luup (which everyone already knows)?
-
@toggledbits yep, I will change it in next build. I'm onto it as we speak. On my system I have few plug-ins, no one is using an IP and I'm still experiencing memory leaks. But I will probably just move everything to openLuup and use the Vera as a radio system.
@therealdb said in Help with Luup Reloads:
yep, I will change it in next build. I'm onto it as we speak.
One more thing... some versions of Luup have trouble returning the status from
os.execute(). They said they have fixed it in the newer beta builds (5363/4/5), but it's concerning that it could be broken at all (should be straightforward, not unstable), and Edward's response to me when queried was a bit uncertain. So I've started moving away from using the return value under Luup and started doing error detection other ways (e.g. does the file I expect now exist?). -
@akbooer said in Help with Luup Reloads:
Yes, this is, indeed, an issue, although NOT one, I would say, for openLuup.
Sorry, did I miss that this was openLuup? Or are you just confirming that openLuup is better than real Luup (which everyone already knows)?
@toggledbits said in Help with Luup Reloads:
Sorry, did I miss that this was openLuup?
Oooh, hope not... NO, just checked...
@pabla said in Help with Luup Reloads:
Recently I have been getting constant reloads on my Vera Plus
@toggledbits said in Help with Luup Reloads:
are you just confirming that openLuup is better than real Luup
Er, yes, just that, really. Let's say that this is one feature I chose not to emulate.
-
@pabla I found a small problem, and I'll fix it in a moment. Please wait for a new release.
--
On a mission to automate everything. -
@pabla I found a small problem, and I'll fix it in a moment. Please wait for a new release.
-
@therealdb No rush, just reporting back
@pabla 1.51-hotfix is on GitHub.
- programs duplication is now fixed, so a reconfiguration is OK
- IP is now a variable (and it's automatically migrated - don't worry)
- temp files are correctly deleted
- I've tracked the problem with infinite stations - and I'm working on a permanent fix. this seems to be related to reloads and I'll investigate this further in the next days.
Give it a try!
--
On a mission to automate everything. -
One thing to add here, a possibility: I notice that the plugin is using the 'ip' attribute to store the IP address of the controller. I have found that this causes a lot of instability. Luup has certain automatic things that it does in the background to try to open connections when the IP is stored on that attribute. It's all part of their built-in automatic I/O for serial and IP connections, which this plugin doesn't use. But Luup will try, try and retry forever to start and maintain a connection to that IP. I believe that this is at least one source of a memory leak -- I suspect their error handling on connection failure is not completely cleaning up after itself, so the system leaks memory, and/or possible even sockets. I discovered this some years ago and switched all of my plugins to just use state variables for the IP. My systems do not restart due to memory leaks, and memory usage is generally flat.
-
@pabla 1.51-hotfix is on GitHub.
- programs duplication is now fixed, so a reconfiguration is OK
- IP is now a variable (and it's automatically migrated - don't worry)
- temp files are correctly deleted
- I've tracked the problem with infinite stations - and I'm working on a permanent fix. this seems to be related to reloads and I'll investigate this further in the next days.
Give it a try!
-
@therealdb So I updated to the latest hot fix, and the files still aren't getting deleted. I have a fill from 11:06am local time and its 11:27am. Do they auto delete after a longer time?
@pabla nope, this should be performed at every http call. This is weird. I’ve just deleted mine with the plugin and it’s working. Try to delete them by hand for the last time and let’s see if it’s working from now on.
--
On a mission to automate everything. -
@pabla nope, this should be performed at every http call. This is weird. I’ve just deleted mine with the plugin and it’s working. Try to delete them by hand for the last time and let’s see if it’s working from now on.
-
@therealdb Manually deleted the files and they aren't auto deleting still. This is really weird
-
Okay good news, so I uploaded the file via WinSCP since I noticed I had doubles of each file type one of the doubles was a .lzo file type. Now the files are deleting properly too. Question for everyone: Does the .lzo compression make a difference? Every time I get Github files I decompress and then drag them into the Luup Files section under Develop Apps. But I have began to notice that I have a lot of files with the .lzo extension
