SuperDuper! Failure [Archive] - Shirt Pocket Discussions

Nick

06-10-2009, 03:37 PM

I have SD! scheduled to do a daily backup. The last one (early this morning) failed. I was able to retrieve information from the log, and it had a series of error entries:

...
...
...

| 01:17:59 AM | Info | /.Spotlight-V100
| 01:17:59 AM | Info | Preserving /.Spotlight-V100
| 01:17:59 AM | Info | Ignoring /Desktop DF
| 01:17:59 AM | Info | /Users
| 01:18:35 AM | Error | LOGGED EXCEPTION: NSAccessibilityException, reason: "AXEnabled" attribute unsupported by: <NSPanel: 0x1c9edfa0>, userInfo: {NSAccessibilityErrorCodeExceptionInfo = -25205;}
| 01:18:35 AM | Error | LOGGED EXCEPTION: NSAccessibilityException, reason: "AXChildren" attribute unsupported by: <_NSThemeCloseWidgetCell: 0x1ca034c0>, userInfo: {NSAccessibilityErrorCodeExceptionInfo = -25205;}
| 01:18:35 AM | Error | LOGGED EXCEPTION: NSAccessibilityException, reason: "AXChildren" attribute unsupported by: <_NSThemeWidgetCell: 0x1ca02140>, userInfo: {NSAccessibilityErrorCodeExceptionInfo = -25205;}
| 01:18:35 AM | Error | LOGGED EXCEPTION: NSAccessibilityException, reason: "AXChildren" attribute unsupported by: <_NSThemeWidgetCell: 0x1c9e4530>, userInfo: {NSAccessibilityErrorCodeExceptionInfo = -25205;}
| 01:18:35 AM | Error | LOGGED EXCEPTION: NSAccessibilityException, reason: "AXChildren" attribute unsupported by: <NSButtonCell: 0x1ca1ec10>, userInfo: {NSAccessibilityErrorCodeExceptionInfo = -25205;}
| 01:18:35 AM | Error | LOGGED EXCEPTION: NSAccessibilityException, reason: "AXChildren" attribute unsupported by: <NSButtonCell: 0x1c96a7c0>, userInfo: {NSAccessibilityErrorCodeExceptionInfo = -25205;}
| 01:18:35 AM | Error | LOGGED EXCEPTION: NSAccessibilityException, reason: "AXChildren" attribute unsupported by: <NSButtonCell: 0x1c962270>, userInfo: {NSAccessibilityErrorCodeExceptionInfo = -25205;}
| 01:18:35 AM | Error | LOGGED EXCEPTION: NSAccessibilityException, reason: "AXChildren" attribute unsupported by: <NSButtonCell: 0x1c928390>, userInfo: {NSAccessibilityErrorCodeExceptionInfo = -25205;}

An SD! failure has only happened to me a few times before, and it was the kind of thing that took care of itself after I rebooted and manually ran the backup. Today, rebooting didn't help. In fact, I found the iMac to be rather unresponsive while SD! was attempting to create its backup (the spinning beachball kept on appearing). After a short while, SD! seemed to stall after having run through what appeared to be approximately the same number of files (about 0.5 million), and I had to quit SD! I repeatedly attempted a manual backup (usually after rebooting), but each time the results were the same: SD! would stall, and I’d have to quit. The last time it happened (a short while ago) I checked the log, and found that SD! was stalling at about the same point in its activity; after about a half hour of no further activity, I quit SD!:

...
...
...

| 10:52:37 AM | Info | /.Spotlight-V100
| 10:52:37 AM | Info | Preserving /.Spotlight-V100
| 10:52:37 AM | Info | Ignoring /Desktop DF
| 10:52:37 AM | Info | /Users
| 11:24:36 AM | Info | User terminated processing of transcript...

I ran Disk Utility as well as TechTool Pro, and both drives (internal and external SD!) appeared to be fine.

Suggestions?

Nick

06-11-2009, 02:04 AM

dnanian

06-11-2009, 05:44 AM

Yes. The problem here is that you were running Safari while we were backing up, and it created (and deleted) that 'lock' file as we were copying (and deleted it out from under us).

Repeat the backup after quitting Safari and it should work fine.

Nick

06-11-2009, 03:10 PM

Nick

06-11-2009, 03:11 PM

dnanian

06-12-2009, 01:09 PM

The one that failed with all the (null)s was definitely Safari:

| 01:18:32 AM | Info | Unable to create hard link from /Volumes/Nick's HD Clone/Users/Nick/Library/Safari/lock to (null)

That's because 'lock' was deleted out from under us.

The other issue is likely that it was copying a large file, somewhere in your Home folder...

Nick

06-12-2009, 05:18 PM

The one that failed with all the (null)s was definitely Safari:

| 01:18:32 AM | Info | Unable to create hard link from /Volumes/Nick's HD Clone/Users/Nick/Library/Safari/lock to (null)

That's because 'lock' was deleted out from under us.

The other issue is likely that it was copying a large file, somewhere in your Home folder...

Thanks, Dave.

I will let SD! continue to do its scheduled backups, and see what happens. But I never had a problem with other apps running while SD! was backing up. Was that just dumb luck, or do I need to make sure nothing else is running during SD!'s scheduled backups? (The Manual says that quitting other apps isn't "strictly necessary," but also indicates that it's "a good practice.")

I also never had SD! fail as a result of stalling and (apparently) timing out while copying a "large" file...and the largest file in my Home folder has always been my Entourage Identity, which is about 4 GB. Is there any obvious reason it should suddenly—and coincidentally—become a "choke point?"

dnanian

06-12-2009, 05:28 PM

That's the thing. It's not strictly necessary, but you can run into problems -- like this one. I don't know why any given file would "suddenly" become a choke point, but something has. If you drop me some email, I can provide you with a command that'll help you determine what file is being copied at that point in time.

Nick

06-12-2009, 05:37 PM

... If you drop me some email, I can provide you with a command that'll help you determine what file is being copied at that point in time.

PM, or forums - at - shirt-dash-pocket-dot-com?

dnanian

06-12-2009, 05:38 PM

support - at - etc.

Nick

06-12-2009, 05:48 PM

support - at - etc.

Check your Support inbox.

Nick

06-16-2009, 07:13 PM

...I can provide you with a command that'll help you determine what file is being copied at that point in time.

Thanks...It worked like a charm :). Apparently, SD! was getting hung up on my 4 GB Entourage Identity. Why it would do so all of a sudden is puzzling.

Having stalled on that file, I have been quick to quit all other open apps when SD! begins its scheduled backup. But I eventually found that if I let SD! "hang" on that Entourage file for a while (actually, for quite a while), it finally stopped timing out and continued with the backup successfully. So, that's what it seems to be doing now: Hang for a long time, but eventually proceed again to complete the backup successfully.

I wonder what caused all of this to begin with? It certainly seems like Safari somehow was the "trigger" (though it only was involved that first time); right after that, the failures seemed to be due to the hangs on the Entourage file. But now, SD! "recovers" before "giving up."

(BTW: I really don't use Terminal except on rare occasions (like this time), as I'm not comfortable with it (the one time I really attempted to do something "significant" (by "blindly" following someone's poor instructions), I wiped out my desktop!). I did notice that each time I opened Terminal to use the command you provided, as soon as Terminal opened (before I entered any command/password), it informed me "You have mail." The handful of times I've opened Terminal in the past, I never ran into that. And my email habits/behavior haven't changed, so I wonder why I'm receiving that message. But I guess that's not an SD! question, is it? :o)

dnanian

06-16-2009, 10:17 PM

It's likely mail that a system tool has sent you.

As far as "all this" goes, hard to say. You should generally quit Entourage, though, before copying its data.

Nick

06-16-2009, 11:42 PM

It's likely mail that a system tool has sent you.
Where would it be located (certainly not in Mail.app or Entourage)?

... You should generally quit Entourage, though, before copying its data.
I use an automator workflow that quits Entourage and copies its data to a "backup" folder in my docs folder. That's the file that SD! gets hung-up on.

chris_johnsen

06-17-2009, 12:53 AM

Where would it be located (certainly not in Mail.app or Entourage)?

Note: I will be describing what I see on my Tiger machine. If you have Leopard some details might be different.

System-based email is in the file /var/mail/username (where username is your user's "short user name"). Mail is really geared towards Internet email, so it does not offer a direct way to check this mailbox. You can, however, import this system email into Mail. Choose File > Import Mailboxes…; select Other (the key phrase here is "mbox file"); click Continue; press ⌘⇧G (Command-Shift-G); type /var; click Go; select mail; click Choose; make sure your short user name is checked in the Items to import list; click Continue; read the displayed info about where to find the imported messages; click Done.

Entourage should also be able to do the job. The key words you want to look for are import and mbox. Then just point it to your /var/mail/username file.

Nick

06-17-2009, 02:48 AM

Note: I will be describing what I see on my Tiger machine. If you have Leopard some details might be different.

System-based email is in the file /var/mail/username (where username is your user's "short user name"). Mail is really geared towards Internet email, so it does not offer a direct way to check this mailbox. You can, however, import this system email into Mail. Choose File > Import Mailboxes…; select Other (the key phrase here is "mbox file"); click Continue; press ⌘⇧G (Command-Shift-G); type /var; click Go; select mail; click Choose; make sure your short user name is checked in the Items to import list; click Continue; read the displayed info about where to find the imported messages; click Done.

Entourage should also be able to do the job. The key words you want to look for are import and mbox. Then just point it to your /var/mail/username file.

Thanks for the instructions, Chris.

I found daily messages going back over two months (and apparently still ongoing):

-----------------------------------------------------------------------------------------------------------------------

From: Nick @ nicks-imac.local (Cron Daemon)
Subject: Cron <Nick@nicks-imac> open ﬁle:///Users/Nick/Library/Application%20Support/
SuperDuper%21/Scheduled%20Copies/Smart%20Update%20Nick%27s%20HD%20Clone%20from
%20Nick%27s%20HD%201.sdsp/Copy%20Job.app
Date: April 11, 2009 1:15:01 AM EDT
To: Nick @ nicks-imac.local
__________________________________________________ _____________________________________________

The file /Users/Nick/Library/Application Support/SuperDuper!/Scheduled Copies/Smart Update Nick's HD Clone from
Nick's HD 1.sdsp/Copy Job.app does not exist.

-----------------------------------------------------------------------------------------------------------------------

They are all identical, one for each daily backup, coincident with the initiation of each backup, since April 11.

Any idea what they mean (and what is causing them)?

chris_johnsen

06-17-2009, 04:31 AM

I do not do (automatically) scheduled backups, so I am not sure.

If your scheduled backups are working despite these emails showing that it is not able to start the "Copy Job" app, then I would guess that these emails are from "left over" scheduler entries that were deleted but somehow left in the crontab. The error in the email seems to indicate that the backup driver app for that scheduled backup it no longer there. I would guess that the whole .sdsp bundle was deleted from the ~/Library/Application Support/SuperDuper!/Scheduled Copies directory.

The app's path seems to indicate that the erroneous entry was for a scheduled backup from "Nick's HD 1" (note the trailing 1) to "Nick's HD Clone". The trailing "1" seems to indicate that you might have had two volumes named "Nick's HD" active at the time this entry was created. SuperDuper! actually identifies each volume its special, unique identifier, not its user visible name. So it is not a problem to have multiple volumes with the same name, but it is probably not very common unless you have just restored a failed internal drive or something.

I will have to defer to Dave as to whether SuperDuper!'s scheduler function can cleanup this bogus looking crontab entry or if it needs to be done by hand to stop your daily of system emails.

dnanian

06-17-2009, 07:58 AM

I don't know why an 'extra' crontab entry might be there, but I'd delete your existing schedules, then open Terminal and type:

crontab -r

(followed by return)

Then, start SD! and recreate your schedule(s). That should remove any extra crontab entries and stop the email.

Nick

06-17-2009, 10:54 AM

I do not do (automatically) scheduled backups, so I am not sure.

If your scheduled backups are working despite these emails showing that it is not able to start the "Copy Job" app, then I would guess that these emails are from "left over" scheduler entries that were deleted but somehow left in the crontab. The error in the email seems to indicate that the backup driver app for that scheduled backup it no longer there. I would guess that the whole .sdsp bundle was deleted from the ~/Library/Application Support/SuperDuper!/Scheduled Copies directory.

The app's path seems to indicate that the erroneous entry was for a scheduled backup from "Nick's HD 1" (note the trailing 1) to "Nick's HD Clone". The trailing "1" seems to indicate that you might have had two volumes named "Nick's HD" active at the time this entry was created. SuperDuper! actually identifies each volume its special, unique identifier, not its user visible name. So it is not a problem to have multiple volumes with the same name, but it is probably not very common unless you have just restored a failed internal drive or something.

I will have to defer to Dave as to whether SuperDuper!'s scheduler function can cleanup this bogus looking crontab entry or if it needs to be done by hand to stop your daily of system emails.

There's only one volume named "Nick's HD" (it resides on my internal drive). SD! backs it up to a volume (named (appropriately enough) "Nick's HD Clone") on an external drive.

Nick

06-17-2009, 10:57 AM

I don't know why an 'extra' crontab entry might be there, but I'd delete your existing schedules, then open Terminal and type:

crontab -r

(followed by return)

Then, start SD! and recreate your schedule(s). That should remove any extra crontab entries and stop the email.

I'll give it a try. (If nothing else, perhaps I'll overcome my FOT ("Fear of Terminal") :rolleyes: ).

Nick

06-21-2009, 04:30 AM

I don't know why an 'extra' crontab entry might be there, but I'd delete your existing schedules, then open Terminal and type:

crontab -r

(followed by return)

Then, start SD! and recreate your schedule(s). That should remove any extra crontab entries and stop the email.

I followed your instructions, but it didn't help: The very next time I opened Terminal, I was still greeted with "You have mail."

Thinking that I might have made an error, I then re-entered "crontab -r" and hit return. Terminal responded with "crontab: no crontab for Nick". So, it seems that I did do it right...if "right" means getting rid of "crontab" (whatever that file may be).

dnanian

06-21-2009, 08:56 AM

You're going to get "You Have Mail" until you delete all the mail that's there. The point was to prevent any more mail from being generated.

Nick

06-21-2009, 09:54 AM

You're going to get "You Have Mail" until you delete all the mail that's there. The point was to prevent any more mail from being generated.

I'm not sure whether that's the dumbest question I've ever asked; if not, it certainly is among the Top Ten. :o In my own (feeble) defense, all I can do is point to (and blame it on) a severe lack of sleep at the time I posted.

Sorry...and thanks!

dnanian

06-21-2009, 09:55 AM

It wasn't stupid at all, Nick. :)

Nick

06-21-2009, 10:09 AM

It wasn't stupid at all, Nick. :)

You're way too kind, Dave.

(BTW: Any suggestions for reference material re: Terminal that won't make my eyes glaze over?)

dnanian

06-21-2009, 10:47 AM

Pretty much everything you're going to read about the various shells and commands is going to be dry. But one of the O'Reilly online books might help -- it's not so much Terminal as it is "Unix"...

sjk

06-21-2009, 02:26 PM

From Hivelogic - My First PeepCode Screencast: Meet the Command Line (http://hivelogic.com/articles/view/meet-the-command-line):

Meet the Command Line is a 70 minute screencast geared for people who have never used the UNIX command line, or are learning it for the first time.

If you can afford $9.

dnanian

06-21-2009, 04:08 PM

Hey, good catch - I'm sure Dan did a good job with that.