UZB/RaZberry Firmwares - Update

[rafale77]

I researched this quite a bit as well. The process actually does not reload. The HUP is a signal to restart a process yes, which in this case is the logging. I have used it for quite some time. Unlike a "luup reload" for the vera it doesn't kill the program and reload it. You can see that from the program load date. The vera's log rotate uses the similar function to log rotate as I said, without reloading the memory or the program. It is also what the embedded razberry image does. This all depends on how the binary is programmed.

[CatmanV2]

I had to go and check this. It rather depends on the server it's directed at. Apache will re-read, for example, but not restart. I have no idea what the z-wave-server will do but it should be really easy to tel by running it and seeing the process details in ps

C

[DesT]

killall -HUP z-way-server, this command will ask the process z-way-server to "reload" and doing that, it will release the "lock" on the log file IF the application if locking the file OR just "appending" data at the end without locking!

The HUP parameter in KILL is not reloading the application ITSELF like a stop/start. The kill signal, is send to the process and ask the application IF he want to reload!

If the program/application/daemon/whatever have NO function on how to "reload", it will do nothing at all, but in case it can handle the reload, it's always like a restarting the process.

If I'm doing a KILL -HUP to a webserver like Apache or nGinx, it will reload the configuration for changes.

All I'm saying, it's that killing -HUP a process for log rotation is not required if the application didn't lock the file. You can try that by doing the command

> logfilename

This will empty the file, if the filesize is the same even after that, the file is lock at the filesystem level and if the file is back to 0, that mean the file is empty with no lock and you don't need to kill HUP the process!

[rafale77]

@CatmanV2

To illustrate this, I took a screenshot of my VM ps aux: I reloaded openLuup 2 days ago.

I have been doing daily log rotate on z-way-server but have booted it since April 10th, date at which I upgraded to 3.0.6

@DesT, I tried without the kill HUP process... It does not work. The log file is actually "moved" by the logrotate and it just stops logging. This is also well documented by @PoltoS on the zwave.me forum and follows their recommendations there.

[DesT]

@PoltoS I think you need to check how you handle logging, if they need to kill -HUP the process, that's 'cause you lock the file instead of just appending at the end!

[prophead]

@rafale77 i know how to use cron. how to get logrotate functionality to have 5 backups?

[rafale77]

@prophead

I am just now getting to understand what you are trying to do...
You can use the same script above and change the file to the openLuup user-data.json file and change the number "9" to "5".
Also remove the "killall" line.

[akbooer]

@prophead said in logrotate for z-way-server:

could I use this make automated backups of my openluup user_data file?

Just to say that openLuup has a built-in CGI to accomplish this (files backed up to the cmh-ludl/backups/ folder in LZAP compressed form by default.) These may be used to directly restore an openLuup configuration. You could trigger the backup with a timed scene.

The openLuup console Backup page shows the available backups...

[rafale77]

@akbooer

I really wanted to post the same thing earlier... but... it would be nice to have a "restore" function on this page to make the functionality whole...

[prophead]

I use the backups manually. I want automated with rotation. Why hack lua to do this if its easy in os?

[akbooer]

@prophead said in logrotate for z-way-server:

I want automated with rotation.

The openLuup plugin has a SendToTrash action which internally uses a file retention manager which can limit the number of files in a folder to:

• the most recent N
• files younger than a certain number of days old
• only certain file types

Again, this can be run from a regularly scheduled scene. Files are temporarily moved to the Trash folder but may be permanently deleted by the EmptyTrash action of the openLuup plugin.

The same procedure can be used to manage image files.

I don't call this 'hacking Lua'

[prophead]

@akbooer So I'm trying to do rotated backups the openLuup way, and expected backup to be an action. Apparently not. What is the best way to call a local cgi? luup.inet.wget(http://127.0.0.1/backup.cgi)?

[prophead]

Can't seem to get the SendToTrash action to work either, heres my attempt:
luup.call_action ("openLuup","SendToTrash",{Folder="/etc/cmh-ludl/backup",MaxDays="",MaxFiles="10",FileTypes="lzap"},2)
I really wish you would put examples in your documentation.
the log files show luup_log:2: applying file retention policy... luup_log:2: ...finished applying file retention policy
but the files are still there.
Any help?
|-<:)

[akbooer]

@prophead said in logrotate for z-way-server:

expected backup to be an action. Apparently not.

Yes, I would have expected that too... except that we are talking about a Vera feature here, which is used by the AltUI interface, so it has to be done this way to be compatible.

What is the best way to call a local cgi?

In this case, you need:

luup.inet.wget "/cgi-bin/cmh/backup.sh?"

HTH

[akbooer]

@prophead said in logrotate for z-way-server:

Can't seem to get the SendToTrash action to work either, heres my attempt:

Yes indeed, another appallingly badly documented feature.

In order to prevent an ill-advised programmer from wreaking havoc, absolute paths are not allowed. So you should use:

luup.call_action ("openLuup","SendToTrash",{Folder="backup",MaxDays="",MaxFiles="10",FileTypes="lzap"},2)

In addition, certain key folders are denied access, including

openLuup, cgi, cgi-bin, cmh, historian, whisper, files, icons, www

I will try to improve the documentation.

[prophead]

@akbooer Thank you, that worked.