Shutdown forced by UPS

[franconi]

Hi,
The following seems a common scenario for may of us.
I have a UPS that forces a shutdown when the current goes off and the UPS battery is low. How does SD behave in this case, if this happens while SD is making the backup? Is the backup copy left in an incomplete but safe (i.e., readable) state, or is the copy screwed up? I am making the backup to a single disk image in a networked NAS disk.
What would be the best way to handle such case?
cheers
--e.

[dnanian]

Well... it really depends on how the UPS software does the shutdown. If it's a clean shutdown, everything should be safe but incomplete. If it's a "bad" shutdown, nearly anything could happen.

[franconi]

Originally Posted by dnanian

Well... it really depends on how the UPS software does the shutdown. If it's a clean shutdown, everything should be safe but incomplete. If it's a "bad" shutdown, nearly anything could happen.

Well... http://www.shirt-pocket.com/forums/i...lies/smile.gif
It is a typical Mac built-in forced shutdown: it does not depend on the UPS software, but it is the built-in UPS management software of MacOSX Tiger.
Since 10.4.9, Intel Macs (like mine) have a "shutdown -u" option (see man shutdown), that is actually used for UPS forced shutdowns (see the script /usr/libexec/upsshutdown).

So, given the above info, can you comment whether SD will leave the remote disk image safe (i.e., readable although incomplete) after an UPS shutdown?

cheers
--e.

[dnanian]

Give what that script does -- force a shutdown -- it's unlikely an image would be unmounted by Finder before power was removed (since it waits for a dirty close).

[franconi]

Originally Posted by dnanian

Give what that script does -- force a shutdown -- it's unlikely an image would be unmounted by Finder before power was removed (since it waits for a dirty close).

Since we have the possibility to edit/personalise the script in /usr/libexec/upsshutdown, what would you do to manage the whole process properly from the SD point of view, before launching the final shutdown -h?

cheers
--e.

[dnanian]

Well, I'd probably try to kill SDCopy and unmount the image, if any.

[franconi]

Originally Posted by dnanian

Well, I'd probably try to kill SDCopy and unmount the image, if any.

kill -9 ? Or a nicer way to kill :-) ?

[dnanian]

I think a normal kill'll do it, no need to force. Try a SIGTERM or SIGQUIT.

[franconi]

Originally Posted by dnanian

I think a normal kill'll do it, no need to force. Try a SIGTERM or SIGQUIT.

Indeed! I did a kill -TERM $SDCopy.pid and I could re-mount the incomplete image!

Now, I guess that I should do the same for the fsck, and that at the end I could do a kill of the SuperDuper process itself (parent of both SDCopy and fsck).
Or would it work if I kill directly just SuperDuper?

cheers
--e.

[dnanian]

Well, the fsck is happening only during the mount (part of the OS), so the image wouldn't be mounted yet if that was running. I wouldn't kill SD! itself -- not really necessary.

[franconi]

Thanks.
So, now I have added the following to the upsshutdown script (before the shutdown):

killall -TERM SDCopy
hdiutil detach /Volumes/TheBackupDiskImage
hdiutil detach /Volumes/TheRemoteDisk

Ca you comment which is better between -TERM and -QUIT?

[dnanian]

-TERM should be fine; they're not really better.

[franconi]

Thanks for everything. You guys rock!
This is the final version of my addition to the upsshutdown script:

killall -TERM SDCopy
hdiutil detach /Volumes/TheBackupDiskImage
umount /Volumes/TheRemoteDisk