Triggering image save (was: [Vm-dev] Re: RFC: Unix 3.11.3-2116 VM)
David T. Lewis
lewis at mail.msen.com
Wed Sep 2 00:23:22 UTC 2009
On Tue, Sep 01, 2009 at 02:21:02PM -0600, David Farber wrote:
> Here is what happened to me back at the end of March. I was running
> a Seaside/Pier site headless  on CentOS 5. For persistency, Pier
> was supposed to snapshot the image after any relevant changes.
> Somewhere, somehow an error arose in the snapshot codepath, so Pier
> stopped snapshotting the image (even though the rest of the app ran
> fine and was accumulating data). I tried to manually snapshot the
> image (and save precious data) but, because the error was in the
> snapshot codepath, all I managed to do was hang the web interface.
> Out of the box, Seaside doesn't do any error logging  and I wasn't
> running a VM that had IMAGE_DUMP or stack-printing enabled. So I
> was stuck with an image that was running (with unsaved data) but
> completely incommunicado.
This is probably redundant with what Ian previously described, but here
is another way to set up your image to do a save when you send SIGUSR2
to the vm. The image save has little or no impact on the running image
(i.e. no pause while the files are being written) because it is done
in a background OS process.
sigUsr2Semaphore := OSProcess accessor forwardSigUsr2.
sigWatcher := [[sigUsr2Semaphore wait.
(Delay forSeconds: 30) wait] repeat] fork.
This would need to be run at image startup, because #forwardSigUsr2
sets the signal handler only for the duration of the current session.
I guess you could also use cron to schedule periodic image saves.
More information about the Vm-dev