Force Save of user_data?

dklinkman · January 25, 2018, 7:00pm

Just curious if there is a way to force an immediate save of the user_data, vs relying only on the 6 min after restart and then every 60 minute saves? Maybe via the http interface?

I’m interested because I’m trying to automate creation and recovery of openluup in a Docker container, and would like to save the user data immediately after restoring from backup (so I can then tear down the container).

I’m running 18.1.18

-d

akbooer · January 25, 2018, 7:03pm

Well, of course, exiting openLuup will save the user_data. Also, an HTTP request to back it up will do it.

dklinkman · January 25, 2018, 9:03pm

So I need to find the right way to shutdown openLuup. The container I am running is supposed to send a sighup signal to all running processes. But when I shutdown the container the data hasn’t been saved. I think the container logic only gives a process .5 sec to terminate before it sends a sigkill. You’ve given me a path to explore. Thanks.

-d

akbooer · January 26, 2018, 12:15am

An HTTP request to openLuup [tt]&id=exit[/tt] will force an exit.

Sadly, there’s no way to get Lua to handle process signals.

dklinkman · January 26, 2018, 12:24am

Here’s a twist. I haven’t been able to figure out how to cause openLuup to exit normally. Sending a sighup does cause shutdown but there’s no save of the user data. [[ I just saw your comment about lua and signals as I was finishing this post. I may try the ‘exit’ request - thanks for that ]]

So I tried the initiate a backup approach. The backup is created just as expected. But again there is no save of user data. I don’t know what I am doing wrong

This is what I execute in my initialization script, after starting openLuup with the backup file and waiting a short time for it to fully start and load

wget -O - http://localhost:3480/cgi-bin/cmh/backup.sh >/dev/null 2>&1

The backup file is created just fine. But the user data is unchanged

-rw-r--r--    1 root     root         11505 Jan 26 00:09 user_data.json

if it was updated it would be a few hundred k. Yes I know I shouldn’t be running as root.

But this gives me other ideas. I’ll just keep the original backup file around until startup confirms that the user data has been updated (> 100k). If not, just start with the backup like before. This way if the container ends before the normal save, just try again. No need to tear it all down and start from scratch. openLuup lives on a persistent volume by the way. The data plus any subsequent updates survives the ending of the container.

-d

dklinkman · January 26, 2018, 1:40am

Success!! 8) 8) 8) 8) 8)

The exit request works great

wget -O - http://localhost:3480/data_request?id=exit

User data is saved, like immediately and very inline with the initialization of the build. Which is what I was going for.

-rw-r--r-- 1 root root 1914 Jan 26 01:10 openLuup_install.lua -rwxr-xr-x 1 root root 223 Jan 26 01:11 openLuup_reload -rw-r--r-- 1 root root 876039 Jan 26 01:11 user_data.json

Damn, I need to fix the timezone.

And then the process manager for the container takes over and (re) starts openLuup normally.

Started runsvdir, PID is 59 wait for processes to start.... run: crond: (pid 66) 5s run: openLuup_reload: (pid 64) 5s run: rsyslogd: (pid 65) 5s

alpine-openluup:~# ps -ef PID USER TIME COMMAND 1 root 0:00 {boot.sh} /bin/sh /boot.sh 59 root 0:00 runsvdir -P /etc/service log: ........................... 61 root 0:00 runsv rsyslogd 62 root 0:00 runsv crond 63 root 0:00 runsv openLuup_reload 64 root 0:00 {openLuup_reload} /bin/sh ./openLuup_reload 65 root 0:00 /usr/sbin/rsyslogd -n 66 root 0:00 /usr/sbin/crond -f 79 root 0:16 lua5.1 openLuup/init.lua

And on a ‘reasonably’ small image. It will be smaller after I delete all the troubleshooting tools (less, vi, netstat, etc)

dklinkman/alpine-openluup latest 8b3fc2f1fb9c 23 minutes ago 48.5MB

100% happy. Thanks for the suggestions! I learned a lot!

-d

cybrmage · January 26, 2018, 3:43am

That is untrue…

Look at Lua Posix… Signal DOCUMENTATION

The version of the posix module that is included in the Vera firmware is OLD… So the current documentation doesn’t match the implementation (the Vera implementation is not modulized)…

ie:
posix.signal.SIGUSR1 (documented) == posix.SIGUSR1 (implemented)
posix.signal.signal (documented) == posix.signal (implemented)

local POSIX = require("posix")

function Handle_SIGUSR1
  luup.log("received SIGUSR1")
end

POSIX.signal(POSIX.SIGUSR1, Handle_SIGUSR1)

akbooer · January 26, 2018, 10:50am

[quote=“dklinkman, post:6, topic:198404”]Success!!

The exit request works great

wget -O - http://localhost:3480/data_request?id=exit

User data is saved, like immediately and very inline with the initialization of the build. Which is what I was going for.[/quote]

Good, delighted to hear that!

On your earlier comment…

…the backup IS a save of user data. It happens also to be compressed using the LZAP algorithm and so ends up about 5 to 8 times smaller than a user_data.json file. However, it can be used directly as a parameter to the openLuup_reload script to run a saved configuration.

Anyway, you’re sorted.

akbooer · January 26, 2018, 10:54am

That is untrue…[/quote]

…well, you’re quite right, of course. What, perhaps, I should have said is that there’s no native way (or possibly os-independent) way of doing this.

A basic design requirement (in my mind) for openLuup was that it should be platform independent. It does, quite happily, run under Windows. The posix library, of course, does not do this (or, at least, I don’t think so?)

There ARE people who run openLuup on Windows, but I have to admit that the vast majority are on unix/Linux/Posix-like systems.

So thanks for the correction.