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 [1] 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 [2] and I wasn't running a VM that had IMAGE_DUMP or stack-printing enabled[3]. 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. UnixProcess saveImageInBackgroundNicely. (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.
Dave