View Full Version : SuperDuper scheduled backup is taking down my whole system...

12-21-2010, 06:00 AM
QS G4 with dual 1.6GHz cpu (upgraded), 1.5GB RAM, Mac OS X 10.5.8, latest version of SuperDuper...

This system is pretty darned stable other than this problem...

Symptom: SuperDuper launches to run a scheduled backup to a disk image on a remote volume and starts to mount the volume via SMB. The volume does not mount. Instead, a "phantom" icon for the remote volume appears on the desktop with a generic icon and SuperDuper freezes. The entire OS becomes very difficult to use at this point. Keyboard and mouse input will not work consistently. The Finder is completely unresponsive. The kernel_task process takes up 120% of the CPU.

Force-quitting or killing processes, including SuperDuper, the Copy Job app and the Finder do not help. SD remains visible as a zombie process after killing it.

An ordinary restart will timeout. A shutdown command from the Terminal will quit all apps, but never actually shut down the computer. I have to hold down the power button to shut off the computer.

This occurs with no USB or FW devices other than an Apple keyboard and mouse connected during the scheduled backup.

There don't seem to be any logs in the Console corresponding to the time of the initial event.

After a restart, manually launching SD and running the backup from the Scheduled Copies window works perfectly well if I mount the volume from the Finder before launching SuperDuper, but will result in the same problem if I run the scheduled backup without first mounting the volume.

SD was working perfectly well until recently.

I've done 3 things that I can think of that have changed since the last successful scheduled backup. I've updated the OS from 10.5.6 to 10.5.8; I've gotten an iPhone which I sync to this Mac; and I've installed the latest iTunes.

Any troubleshooting suggestions?

12-21-2010, 09:05 AM
Well, all SuperDuper! is doing at that point is resolving an alias to the file, which causes the system & alias manage to mount the network volume, using the credentials in the keychain.

Are you able to mount the network volume yourself? Does it work if the network volume is already mounted?

12-21-2010, 09:38 AM
Are you able to mount the network volume yourself? Does it work if the network volume is already mounted?

Yes and yes.

If I mount the volume from the Finder via "Connect to Server" and then run SuperDuper and have it execute the backup script then it will perform the backup normally with one exception.

The one difference is that I long ago edited the script so that it unmounts the image and network-volume when the backup has completed and it will not unmount them anymore.

The volumes can't be unmounted by simply dragging them to the trash, either. Checking with lsof, I found that Spotlight was keeping the disk image busy. After dragging the image's icon to the Privacy pane in the Spotlight pref's I was able to unmount it.

I have to drag the disk image's icon to the Privacy tab each time after I run the backup script. Spotlight "forgets" that it's not supposed to index the drive after each backup.

But that seems to be unrelated to the main problem and is of far less importance to me than resolving the other problem.

12-21-2010, 12:04 PM
Well, since the thing that you've changed here is the system, and we're certainly not doing anything differently, and we have no kernel components that could possibly lock up your system (but the system itself does), I'd have to suggest an archive-and-install and re-update to the OS version you want...

12-22-2010, 09:23 AM
I'd have to suggest an archive-and-install...

Good advice, but I'd like to make a solid effort to figure out what's wrong before blotting out the evidence with a reinstall. Without knowing what caused it, I could be back in this situation at any time.

One more symptom...

This does not turn in the log every time, but was logged to the Console two of the times when SD froze.

12/21/10 3:35:00 AM com.apple.launchd[1] (0x10cf90.cron[24611]) Could not setup Mach task special port 9: (os/kern) no access

The timing is way beyond coincidence. It is certainly associated with the launch of SuperDuper for the automated backup.

From what I can glean, this error pops up when there's a bad shell command in a crontab file.

12-22-2010, 09:40 AM
That's a very typical error and not a problem (and is not a bad shell command). I've told you what we're doing, and have explained that we don't have anything low-level that might "cause" the lockup. Resolving an alias shouldn't lock up your system unless something's terribly wrong with it.

01-12-2011, 06:54 AM
I figured it out.

It was a statistical fluke.

The backup drive is in one of those horrible Seagate enclosures that is designed to save energy by putting the drive to sleep even while the drive is being accessed.

I had long ago disabled that "feature," but the device appears to have decided to start sleeping the drive again at seemingly random times that just happened to coincide with my backups. My NAS still thought that the drive was still spun up, thus the "phantom" drive icon that would show up when the scheduled backup began.

When I swapped the drive into a new enclosure the backups resumed again without fail.

Thanks for your help.

BTW, One criticism about SD's behavior through this: The application locked up and couldn't be quit when the volume failed to mount correctly. SD ought to have some sort of timeout under this circumstance, logging an error and allowing me to quit it.

01-12-2011, 08:54 AM
There is a timeout, it's just quite long... but you had said your *system* locked up, not just SD... and that you could mount it 'by hand', which is weird if it was spun down and the case never spun it up. Very strange.

01-12-2011, 12:29 PM
There is a timeout, it's just quite long... but you had said your *system* locked up, not just SD... and that you could mount it 'by hand', which is weird if it was spun down and the case never spun it up. Very strange.

The whole OS didn't immediately lock up.

SD locked up, the Finder locked up (and came back in the same state if killed and relaunched) and doing anything in the GUI slowed to a crawl. Other apps that were running at the same time and those apps that I launched from the Dock or from DragThing would work, but they'd be very slow and prone to pinwheeling for a long time.

I tracked it down because after many attempts to reproduce the problem under varying conditions it finally started happening when I was not running SuperDuper. That's why I called it a "statistical fluke." Eventually, the odds played out.

01-12-2011, 04:06 PM
Ah, interesting. Anyway, glad you're all fixed up!