Terminology -- reboot --

JohnRob · February 25, 2018, 9:08pm

Hi,

Reading this forum for a while and I though I knew what a “reboot” was, however not I’m not sure.
I have a VeraPlus, and if I query the controller with “http:///cgi-bin/cmh/log.sh?Device=LuaUPnP” I get the log which shows every 6 minutes a group of lines starting with " -rw-r–r-- 1 root root " See attached.

Is this a reboot or is it something else (hopefully normal)?

Thanks

Part of log:

06 02/25/18 16:00:14.667 Device_Variable::m_szValue_set device: 57 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat variable: CurrentSetpoint was: 68.00 now: 68.00 #hooks: 0 upnp: 0 skip: 0 v:0xde5c08/NONE duplicate:1 <0x769d9520> 06 02/25/18 16:00:14.667 Device_Variable::m_szValue_set device: 57 service: urn:upnp-org:serviceId:TemperatureSetpoint1 variable: CurrentSetpoint was: 68.00 now: 68.00 #hooks: 0 upnp: 0 skip: 0 v:0xde4ed8/NONE duplicate:1 <0x769d9520> 06 02/25/18 16:00:14.667 Device_Variable::m_szValue_set device: 57 service: urn:upnp-org:serviceId:TemperatureSetpoint1 variable: AllSetpoints was: 68.00,1.00,34.50 now: 68.000000,1.000000,34.500000 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x769d9520> 06 02/25/18 16:00:14.668 Device_Variable::m_szValue_set device: 57 service: urn:upnp-org:serviceId:TemperatureSetpoint1 variable: AllSetpoints was: 68.000000,1.000000,34.500000 now: 68.00,1.00,34.50 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x769d9520> 04 02/25/18 16:00:14.679 <Job ID="8423" Name="pollnode #32 5 cmds" Device="57" Created="2018-02-25 16:00:06" Started="2018-02-25 16:00:06" Completed="2018-02-25 16:00:14" Duration="8.578083000" Runtime="8.576756000" Status="Successful" LastNote="" Node="32" NodeType="ZWaveThermostat" NodeDescription="Family_Room"/> <0x769d9520> 02 02/25/18 16:00:14.679 Device_Basic::AddPoll 57 poll list full, deleting old one <0x769d9520> 06 02/25/18 16:00:14.680 Device_Variable::m_szValue_set device: 57 service: urn:micasaverde-com:serviceId:HaDevice1 variable: PollRatings was: 5.00 now: 5.00 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x769d9520> 06 02/25/18 16:00:14.681 Device_Variable::m_szValue_set device: 57 service: urn:micasaverde-com:serviceId:ZWaveNetwork1 variable: LastPollSuccess was: 1519592214 now: 1519592414 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x769d9520> 06 02/25/18 16:00:14.681 Device_Variable::m_szValue_set device: 57 service: urn:micasaverde-com:serviceId:ZWaveNetwork1 variable: ConsecutivePollFails was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x769d9520> 01 02/25/18 16:00:24.165 UserData::WriteUserData saved--before move File Size: 34483 save size 34483 <0x767d9520> 02 02/25/18 16:00:24.166 UserData::TempLogFileSystemFailure start 0 <0x767d9520> 02 02/25/18 16:00:24.187 UserData::TempLogFileSystemFailure 4931 res:1 -rw-r--r-- 1 root root 33 Jan 30 15:00 /etc/cmh/HW_Key -rw-r--r-- 1 root root 33 Feb 26 2016 /etc/cmh/HW_Key2 -rw-r--r-- 1 root root 9 Jan 30 15:00 /etc/cmh/PK_AccessPoint -rw-r--r-- 1 root root 7 Jan 30 15:00 /etc/cmh/PK_Account -rw-r--r-- 1 root root 4666 Feb 25 12:02 /etc/cmh/alerts.json -rw-r--r-- 1 root root 0 Jan 30 00:02 /etc/cmh/cameras -rw-r--r-- 1 root root 423 Jan 30 15:00 /etc/cmh/cmh.conf -rw-r--r-- 1 root root 0 Feb 12 2016 /etc/cmh/devices -rw-r--r-- 1 root root 16383 Feb 3 03:00 /etc/cmh/dongle.4.5.dump.0 -rw-r--r-- 1 root root 16383 Feb 1 03:00 /etc/cmh/dongle.4.5.dump.1 -rw-r--r-- 1 root root 16383 Jan 31 03:00 /etc/cmh/dongle.4.5.dump.2 -rw-r--r-- 1 root root 16383 Jan 30 03:00 /etc/cmh/dongle.4.5.dump.3 -rw-r--r-- 1 root root 16383 Jan 29 23:49 /etc/cmh/dongle.4.5.dump.4 -rw-r--r-- 1 root root 16383 Jan 29 23:49 /etc/cmh/dongle.4.5.dump.5

rigpapa · February 25, 2018, 9:15pm

That’s Luup’s normal cycle of saving user_data. It would be nice if that was less chatty and worrisome-looking, but it’s all harmless. Good, in fact.

HSD99 · February 25, 2018, 9:39pm

Yup. This topic comes up a lot.

02/25/18 16:00:24.165 UserData::WriteUserData saved–before move File Size: 34483 save size 34483 <0x767d9520> This is the line that indicates a successful user data save. As long as your logs have this line, the save was successful, in spire of the nervous-making “UserData::TempLogFileSystemFailure start 0” line.

As @rigpapa points out, Vera chose to do a directory listing to confirm that /etc/cmh/user_data.json.lzo is being written. The listing is overly verbose and scary-looking.

JohnRob · February 25, 2018, 10:47pm

Thank you both for your replys.

I sort of though it was OK since my VeraPlus have been rock solid since I first purchased it (when they first came out). But with all the posts complaining about reboots I figured it was time for me to verify.

HSD99 · February 26, 2018, 12:15am

No worries—I had the same reaction when I first saw those entries the logs.

I think, however, there is a real problem with terminology—Luup restarts are frequently called “reboots” by some folks, which is not correct. “Reboots” should refer to a restart of the OS (which will load and start all processes); “restarts” to the Luup system terminating and being restarted.

JohnRob · February 26, 2018, 10:32pm

@HSD99

Thanks for the additional info. So if I were to make a note for myself it might read:

[ul][li]“Yellow” -rw-r–r-- lines in log = Saving data (every 6 minutes)[/li]
[li]Reboot = complete shutdown of the OS are restarting. I would guess the log would clear on a reboot and some log lines would say so.[/li]
[li]LUUP Restart = Would guess the only effect would be a line in a log file and maybe a missed scene?[/li][/ul]

Am I close?

Thanks
John

HSD99 · February 27, 2018, 2:37am

@John,

Yes. The log colors are sometimes unhelpful, but once you know what to look for, the user_data save every six minutes is easy to spot. If the systems eboots, the log will start over and you can see the various boot messages, including starting LUUP. A LUUP restart will be easy to spot in the log since you will see the something about why LUUP was terminated. You are correct–if a scene was supposed to run the crash may prevent it from running, or if it had delays, the scene will not finish as delays are preserved across a LUUP restart.

The System Monitor plug-in will show you reboots and LUUP restarts.

JohnRob · February 27, 2018, 5:24am

Thanks again

I found the system restarts and LUUP restarts in the System Monitor I had already installed but was only looking at the memory status.

John

HSD99 · February 27, 2018, 5:31am

In my last post, I meant to say that delays “are NOT preserved across a LUUP restart.” :-[

JohnRob · February 28, 2018, 5:19am

Yea I figured that. I know even when reading the post preview I sometimes miss a negative or such. Thanks for the correction though it will likely help in the future.

skogen75 · March 2, 2018, 8:09pm

So just to clarify a bit more…

Vera’s built-in scene triggers and delays are not preserved across a Luup reload.

Am I correct in stating PLEG triggers, delays, and timers are preserved across a Luup reload? What about workflows in AltUI?

In a related subject, I have found that Openremote controller monitoring Vera will survive a Luup reload but will not regain the link upon a Vera reboot. Are the commands in the startup Lua run on reboot or reload or both?