SuperDuper Scheduling/cron failures

[diamondsw]

All good info, and I appreciate the time to educate. Bringing up the UNIX metaphor was a good one, as definitely crystalizes the "many specific parts" approach. I suppose I just wasn't in that mindset due to the presence of aliases, AppleScript, and ".app".

Saying cron is based on launchd is a bit of a stretch. The cron process itself is launched by launchd (since we don't have an "init" anymore), but from then on all cron tasks are handled by cron itself and launchd has nothing to do with them. That's just due to launchd replacing init.

cron was deprecated in 10.4 (four and a half years ago), whether explicitly or implicitly. This "unique" way of scheduling certainly took me forever to find - the only reason I did was when I got error messages as a result of it. Since you require 10.4 or later for SuperDuper, you always have launchd available. From an end-user perspective I can see exactly where launchd is configured (Library/Launch(Agents|Daemons)), monitor, start, and stop processes as needed (launchctl), and make changes easily with a multitude of tools (Lingon, etc). For cron there's no reason to suspect it's running at all since Mac OS X doesn't use it, there are no configuration files on disk that I've been able to find, and the default editor (vi - which I finally managed to change to nano) is about as arcane and unfriendly as it gets.

Unless there's a specific launchd bug on 10.4.11 that I don't know of, I don't see it buying you anything. The only change I see would be writing a plist to /Library/LaunchAgents/ instead of a line to cron.

As for AppleScript vs Objective-C, I can completely empathize. In their attempt to make AppleScript "readable", they certainly made the syntax unpredictable. One of those things that sounds good in theory, but doesn't actually work all that well. However, AppleScript is the only option for most people to automate Mac OS X applications, so it is what it is. Any chance of that "error" keyword getting a tweak?

[dnanian]

Having a new facility that does the same kind of thing cron does doesn't deprecate cron. As I said, there is nothing in cron's man pages that indicates cron is deprecated, and there's no such thing as 'implicit deprecation': something is either deprecated or it isn't. And, in this case, it isn't.

Rewriting things to use launchd rather than cron really doesn't make much sense unless we're bored and have nothing better to do. Doesn't mean it wouldn't be nice, just that it's not necessary (and most end users don't know anything about launchd either; it's not like it's less obscure than cron is).

For all AppleScript's flaws, it is also quite powerful. You can get a lot of done in a few statements... once you figure out what those statements need to be.

The error thing has been on the list for a while... it's just not high priority enough to rise to the top yet...

[sjk]

cron/crontab might be a prerequisite for OS X (since 10.5) to be an "Open Brand UNIX 03 Registered Product".

[diamondsw]

Originally Posted by dnanian

Having a new facility that does the same kind of thing cron does doesn't deprecate cron. As I said, there is nothing in cron's man pages that indicates cron is deprecated, and there's no such thing as 'implicit deprecation': something is either deprecated or it isn't. And, in this case, it isn't.

Just one example from Apple:

Timed Jobs Using cron
The cron daemon is the most common tool for executing a job at a particular time. Although all versions of Mac OS X support cron jobs, beginning in v10.4, the functionality of cron is largely superseded by launchd, and all periodic jobs built into Mac OS X are launchd jobs.
...
Because installing cron jobs requires modifying a shared resource (the crontab file), you should not programmatically add a cron job.
...
Timed Jobs Using launchd
Beginning in Mac OS X v10.4, the preferred way to add a timed job is to use a launchd timed job. A launchd timed job is similar to a cron job, with two key differences: ...

So no, not deprecated. But not for programmatic use, and heavily discouraged. There's a whole lot that falls under "you really shouldn't do this, but we're not going to force you to stop". If you weren't already using launchd elsewhere I could understand the reluctance to switch over - it would be something significant to write, unfamiliar, etc. But it's not - it's already used and well-understood for the backup-on-mount functionality.

The only reason I harp on this is because of what a pain it was trying to track down what was happening when SuperDuper left a spurious entry in the crontab. I wouldn't have spent hours trying to track this error down if it had used the same system as everything else.

I promise I won't post back after this, as it's likely for naught and quite likely just getting annoying. In the meantime, I'll delete all of my scheduled jobs from SuperDuper and use the syntax from the crontab to recreate them as launchd items. Then I won't have to worry about bugs in SuperDuper and I'll be able to easily manage the backup process.

[dnanian]

I really wouldn't say 'strongly discouraged'. I'd say "this is a newer, modern, shinier replacement that has some advantages". I'm aware of that... but, given that it would require rewriting things that are working, it seems an unnecessary change at present.

Honestly, all you had to do regarding the cron job was contact me at support, rather than spend 'hours' tracking it down. I could have helped.

I really think you're making a mistake recreating everything as launchd jobs because you had, for whatever reason, an entry in cron that was abandoned. I can't tell you how many people end up with bogus launchd jobs littering their system after they've deleted an application that installed one. You've learned how to manage a cron job... all you're doing, at this point, is moving into an area where I can't support you, and you may cause problems with future updates.

Isn't it best to retain what's working and not manually rewrite it for no gain?

[diamondsw]

Okay, looks like I will post again. I just deleted all of my scheduled copies due to problems with last night's backup (see my other thread), and SuperDuper still left stray entries in crontab. Twice I've tried to delete scheduled backups, and twice SuperDuper has failed to clean up its own mess.

To recap, fixing this requires:

• Seeing that there is UNIX mail from the failed cron process, and knowing how to read it.
• Knowing cron exists, even though nothing else on the system uses it and it is deprecated - specifically for application-level use.
• Knowing how to use vi or override the EDITOR variable to remove the bogus entry.

Fixing this with launchd would require:

• Delete a plist in a standard location.

If this system worked and was bug-free, you could argue all of this is moot - except it's not. It's a broken feature, but I've seen no intention of fixing it. There's clearly a bug in how SuperDuper interacts with cron, and it's compounded by an arcane system that makes it very difficult to fix. It bears repeating, Apple says specifically that applications should not be using cron:

Because installing cron jobs requires modifying a shared resource (the crontab file), you should not programmatically add a cron job.

It doesn't matter to me anymore; I've given up on SuperDuper being able to schedule jobs properly. If I can't trust something as crucial as backups, then they're worthless to me. I'll script it myself (even though the AppleScript dictionary is still partially broken) - at least then I know what the bugs are and can fix them, and I'll let SuperDuper does what it does best - copy files.

[dnanian]

This is not something I can reproduce. If you can give me a case where we don't clean up the crontab, we can fix the problem. Without that, though, it's not possible.

[Drdul]

I've been afflicted with the same bug as diamondsw. I opened Terminal on my Mac Mini, and found 100+ mail messages basically saying that a scheduled copy does not exist (the messages is that "The file /Users/.../Copy Job.app does not exist"). That's because I removed it a year and a half ago.

I opened the Scheduled Copies window in SD and it's empty. Diamondsw says that to fix this I need to "use vi or override the EDITOR variable to remove the bogus entry" in the afflicted crontab. I'm a Unix noob, so any suggestions as to how to clean up my cron situation would be appreciated.