PDA

View Full Version : Problems with schedules randomly not working


Trium Shockwave
10-31-2008, 02:33 PM
I'm a Mac IT consultant, and I have a number of customers using SuperDuper for scheduled backups. I also use it myself at home to back up my server. On every machine I try it on, I seem to have an issue where at some point the schedules will just stop executing. The machines are set not to sleep and not to spin down the hard drives, but it doesn't seem to help. The fix, once I realize it's happened, is to delete and recreate the schedule. I've also noticed that using the Copy Now button on the Scheduled Copies window will almost certainly break it. This problem has been observed on the following versions of OS X on a number of different machines:

10.4.x Client PPC
10.4.x Client Intel
10.5.x Client
10.5.x Server

My own server is a dual 867mhz Power Mac G4 (Mirrored Drive Doors) running OS X Server 10.5.4. It's backing up both its internal boot drive to another internal drive, and a Firewire attached data drive to another Firewire drive (on the other port). I've experienced the problem with both of these backup sets.

dnanian
10-31-2008, 02:40 PM
If you set these schedules to run 'a few minutes from now', when they're in this state, do they run? I'm not aware of anything that would mysteriously stop all your users' schedules like this, save for things like erasing the externals outside of SD! or something like that.

Trium Shockwave
10-31-2008, 03:41 PM
It is a pretty strange problem. Some of it may be users who aren't listening to what I tell them and either shutting the machines down or logging out. My server though I can verify that's not happening since it runs 24/7 and has very little direct user interaction.

What is it that triggers the automatic copies in SD? Does it install a daemon that launches it, or is there a launchd job set up, or what? Maybe I can narrow down the problem if I know what it is that's supposed to make these schedules happen.

dnanian
10-31-2008, 05:33 PM
It uses cron, and a user-specific crontab.

Trium Shockwave
10-31-2008, 05:56 PM
The first time I looked at crontab -l it was blank. I deleted and recreated the schedules in SuperDuper, then got then did crontab -l again and got following (dummy host name substituted)

0 2 * * 0 open file:///Network/Servers/server.example.com/Volumes/Data/Network\%20Homes/download/Library/Application\%20Support/SuperDuper\%21/Scheduled\%20Copies/Smart\%20Update\%20Server\%20HD\%20Backup\%20from\ %20Server\%20HD.sdsp/Copy\%20Job.app
0 3 * * * open file:///Network/Servers/server.example.com/Volumes/Data/Network\%20Homes/download/Library/Application\%20Support/SuperDuper\%21/Scheduled\%20Copies/Smart\%20Update\%20Data\%20Backup\%20from\%20Data. sdsp/Copy\%20Job.app

So, it seems like SD! is creating little custom app bundles that are stored in ~/Library/Application Support/SuperDuper/Scheduled Copies. I checked and those were present (at least after I had recreated the schedules). The question is, why was the crontab blank? If that's getting dumped for some reason, it would explain why the schedules stop.

dnanian
10-31-2008, 06:18 PM
I don't know: no 'standard' part of OSX deletes the crontab, but perhaps something else you're installing, that's common between you and your clients, is doing so?

Trium Shockwave
11-05-2008, 11:49 AM
The only thing I can think of is that with my server it's a problem related to the account being an Open Directory account. Maybe since it's not a local user account, the crontab is flushed whenever it logs out or the server is rebooted. I've set it up so SuperDuper is running from the local admin account (which was usually not logged in). If that solves the problem, my suspicion will be that my users are having trouble because they aren't following directions. They may be shutting the machine down, putting it to sleep, logging out, or something.

Along those lines, are there any plans to get SuperDuper's automated backups to run as a daemon so they will execute even if the user that configured them isn't logged in? This is pretty easy to do using a launchd job placed in /Library/LaunchDaemons. All you'd need is a headless version of SuperDuper to call with that job and make the backup.

dnanian
11-05-2008, 12:37 PM
A daemon version is something we're considering for the future, yes. But, everything is 'easy to do' when you don't have to actually do it. ;)

Trium Shockwave
11-05-2008, 12:39 PM
True enough. I'm sure Chernobyl looked great on paper.

NovaScotian
11-05-2008, 02:15 PM
Because I've been having the same problem on a PM dual-core G5/2.3 (10.5.5) of backups not always happening, I wrote a script to check:

set tLog to alias (((path to application support from user domain) as text) & "SuperDuper!:Scheduled Copies:Smart Update ACB-500_Bkup from ACB-G5_Leopard 1.sdsp:Logs:")

tell application "Finder"
set LogFiles to (files of tLog)
set tLast to name of last item of LogFiles
set tid to AppleScript's text item delimiters
set AppleScript's text item delimiters to "-"
set tParts to text items of tLast
set item 3 of tParts to first word of item 3 of tParts
set DP to items 1 thru 3 of tParts
set AppleScript's text item delimiters to "/"
set tDate to DP as text
set AppleScript's text item delimiters to tid
display alert "Last Logged Backup on " & tDate giving up after 2
end tell

The script confirms that I am occasionally missing backups. My solution is the same as the OP in this thread -- cancel the scheduled backup and recreate it. After than, things work normally for a while and then die again.

dnanian
11-05-2008, 02:45 PM
You might want to just use Growl to notify on backups instead of writing a special script.

But: when it fails, you get no errors? Does "Copy Now" in the scheduled copies window work? What about setting the backup time to 'a few minutes from now' on the schedule that seems to be failing/not running?

NovaScotian
11-06-2008, 09:49 PM
I'll switch the setting in Growl -- had missed that that it was an option to tell me the copy succeeded (wish it would do either succeed or fail). SuperDuper! is enabled in the Growl Pref Pane.

Copy works perfectly normally. I don't get any errors (or a growl notification) when a scheduled backup fails, it just doesn't happen.

dnanian
11-06-2008, 10:51 PM
OK, so... next time it does this, please try editing the time for the backup to see if that runs...

NovaScotian
11-11-2008, 10:56 AM
If I set it for 5 minutes later, it works. There are a number of warnings of the type:

11/11/08 10:27:04 AM SuperDuper![19765] .scriptSuite warning for attribute 'boundsAsQDRect' of class 'NSWindow' in suite 'NSCoreSuite': 'NSData<QDRect>' is not a valid type name.
11/11/08 10:27:04 AM SuperDuper![19765] .scriptSuite warning for type 'NSTextStorage' attribute 'name' of class 'NSApplication' in suite 'NSCoreSuite': AppleScript name references may not work for this property because its type is not NSString-derived.
11/11/08 10:27:04 AM SuperDuper![19765] .scriptSuite warning for type 'NSTextStorage' attribute 'lastComponentOfFileName' of class 'NSDocument' in suite 'NSCoreSuite': AppleScript name references may not work for this property because its type is not NSString-derived.
11/11/08 10:27:04 AM SuperDuper![19765] .scriptSuite warning for attribute 'boundsAsQDRect' of class 'NSWindow' in suite 'NSCoreSuite': 'NSData<QDRect>' is not a valid type name.
11/11/08 10:27:04 AM SuperDuper![19765] .scriptSuite warning for type 'NSTextStorage' attribute 'title' of class 'NSWindow' in suite 'NSCoreSuite': AppleScript name references may not work for this property because its type is not NSString-derived.
11/11/08 10:27:04 AM SuperDuper![19765] .scriptSuite warning for superclass of class 'NSAttachmentTextStorage' in suite 'NSTextSuite': 'NSString' is not a valid class name.
11/11/08 10:35:03 AM SuperDuper![19812] .scriptSuite warning for attribute 'boundsAsQDRect' of class 'NSWindow' in suite 'NSCoreSuite': 'NSData<QDRect>' is not a valid type name.
11/11/08 10:35:03 AM SuperDuper![19812] .scriptSuite warning for type 'NSTextStorage' attribute 'name' of class 'NSApplication' in suite 'NSCoreSuite': AppleScript name references may not work for this property because its type is not NSString-derived.
11/11/08 10:35:03 AM SuperDuper![19812] .scriptSuite warning for type 'NSTextStorage' attribute 'lastComponentOfFileName' of class 'NSDocument' in suite 'NSCoreSuite': AppleScript name references may not work for this property because its type is not NSString-derived.
11/11/08 10:35:03 AM SuperDuper![19812] .scriptSuite warning for attribute 'boundsAsQDRect' of class 'NSWindow' in suite 'NSCoreSuite': 'NSData<QDRect>' is not a valid type name.
11/11/08 10:35:03 AM SuperDuper![19812] .scriptSuite warning for type 'NSTextStorage' attribute 'title' of class 'NSWindow' in suite 'NSCoreSuite': AppleScript name references may not work for this property because its type is not NSString-derived.
11/11/08 10:35:03 AM SuperDuper![19812] .scriptSuite warning for superclass of class 'NSAttachmentTextStorage' in suite 'NSTextSuite': 'NSString' is not a valid class name.
11/11/08 10:51:10 AM SuperDuper![20072] .scriptSuite warning for attribute 'boundsAsQDRect' of class 'NSWindow' in suite 'NSCoreSuite': 'NSData<QDRect>' is not a valid type name.
11/11/08 10:51:10 AM SuperDuper![20072] .scriptSuite warning for type 'NSTextStorage' attribute 'name' of class 'NSApplication' in suite 'NSCoreSuite': AppleScript name references may not work for this property because its type is not NSString-derived.
11/11/08 10:51:10 AM SuperDuper![20072] .scriptSuite warning for type 'NSTextStorage' attribute 'lastComponentOfFileName' of class 'NSDocument' in suite 'NSCoreSuite': AppleScript name references may not work for this property because its type is not NSString-derived.
11/11/08 10:51:10 AM SuperDuper![20072] .scriptSuite warning for attribute 'boundsAsQDRect' of class 'NSWindow' in suite 'NSCoreSuite': 'NSData<QDRect>' is not a valid type name.
11/11/08 10:51:10 AM SuperDuper![20072] .scriptSuite warning for type 'NSTextStorage' attribute 'title' of class 'NSWindow' in suite 'NSCoreSuite': AppleScript name references may not work for this property because its type is not NSString-derived.
11/11/08 10:51:10 AM SuperDuper![20072] .scriptSuite warning for superclass of class 'NSAttachmentTextStorage' in suite 'NSTextSuite': 'NSString' is not a valid class name.

but the backup seems to be fine. This time, I erased ALL previous schedule lines, closed the schedule window, re-opened it to get a new schedule sheet, and entered a new schedule to the blank page. The previous ones always said that the last backup was back in May. Now the new one has it right.

There was also this message in the System Log (might be related):

Nov 11 10:35:00 ACB-G5-2 com.apple.launchd[1] (0x10e790.cron[19803]): Could not setup Mach task special port 9: (os/kern) no access

Trium Shockwave
11-11-2008, 11:06 AM
So far since moving SD!'s schedules to the local user account, it hasn't stopped, though sometimes it takes several weeks before the problem arises. I am hopeful this solved it though.

dnanian
11-11-2008, 11:09 AM
Those warnings are just fine (and expected - they're compatibility warnings from the script dictionary). The port 9 thing is also no problem.

dnanian
11-11-2008, 11:10 AM
Glad to hear it, Trium Shockwave... keep me informed.

NovaScotian
11-12-2008, 12:14 PM
My scheduling seems to have stopped completely. Works when I test it shortly after it's set, doesn't work when it's set 15 or twenty minutes after I leave the machine (during which time its screens sleep, and possibly its HDs do too but the computer does not).

Clearly time for a different approach; use the Energy Saver wakeup setting and schedule there.

I'd also love to know why, when I discard an old schedule and start a new one, the schedule sheet always announces that the last copy was on Wed. May 28 at 7:18 PM. Is it time to discard the preferences file, reload SuperDuper from a fresh copy, and start over?

dnanian
11-12-2008, 12:47 PM
Please delete your schedules, quit SD! and the remove the 'Scheduled Copies" folder in Library/Application Support/SuperDuper! (off your Home); that should resolve any weirdness in the window.

Why it would run 'one minute from now' but not '15 minutes from now' I have no idea, other than the factors I've listed in the User's Guide. Does your screen saver have a password, perhaps?

NovaScotian
11-12-2008, 06:24 PM
I decided on the kill or cure method. I searched for and deleted every SD! file I could find, several caches, com.blacey.SuperDuper!, com.blacey.plist, the folder in ~/Library/Application Support, the app., reinstalled, reregistered, ran a fresh backup, and scheduled another for 3:10 AM (the Energy Saver will wake the machine at 3 AM).

I should note that there were more files to delete than were recreated when I started up again; particularly several old caches, probably from version 1.

We'll see how that goes.

My ScreenSaver does not require a password because I want to be able to tunnel into the machine.

dnanian
11-12-2008, 07:19 PM
Wake at 3:09am, not 3am. One minute before, always.

NovaScotian
11-13-2008, 11:55 AM
No backup this morning. Scheduling simply doesn't work on my machine. No log entries after 03:09 wakeup for SuperDuper!. Time Machine backed up at 03:20 and Meteorologist updated its weather report just before that, and another wakeup appleScript ran properly, so the machine was awake and functioning.

I'm through fiddling, however -- I'll write an AppleScript to do it on wakeup if the time is right. Sometimes you can't win, Dave -- don't spin your wheels -- there's something odd about my setup.

I was wrong. I just came back to my machine at 3:10 PM, and SuperDuper! was running a backup. Doh -- I thought it was a 24 hour clock, completely missing the AM/PM setting. Pardon my undeserved gripe!!

NovaScotian
11-14-2008, 08:54 PM
Now working properly. :)

alphamac
04-01-2009, 02:42 AM
Trium Shockwave, did staying logged in as a local user fix the problem for you? I read your post and I am in exactly the same situation. The schedules run fine for a while, and then just stop, no warning, no error, just don't run anymore, although the schedule still shows the next attempt will be made at the correct time.

I also have a client where an OD user is logged in to the server where the backup runs (or doesn't, in this case).

This has been an issue for a while now...
am

Trium Shockwave
04-02-2009, 02:07 PM
Yes, arranging things so the SD backup schedules are configured in the local account seems to have solved the problem. It is a little annoying that the crontab seems to dump from network accounts at logout. Apple has been trying to push everyone away from cron and StartupItems and onto launchd though.

alphamac
04-08-2009, 03:16 AM
Thanks for the answer. It's not an option form me to do that with these guys, it would cause too many other issues to have the user that's logged in as a local user. It's good to know what's causing the problem though, even if there's no real fix yet. It's seemed random to me, but this suggests that the user is either logging out, or my client is restarting the server form time to time, so now I at least have something to check.
Many thanks,
am