Shirt Pocket Discussions

Shirt Pocket Discussions (https://www.shirt-pocket.com/forums/index.php)
-   General (https://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   SuperDuper Scheduling/cron failures (https://www.shirt-pocket.com/forums/showthread.php?t=6130)

diamondsw 03-13-2010 04:50 PM

SuperDuper Scheduling/cron failures
 
First off, a scheduled copy that I previously deleted is still attempting to run. Nightly, I get messages in my UNIX mailbox (nothing I ever would have noticed, except for a stray line in the terminal one day) complaining that cron can't find a file, and points to my old saved settings that had been scheduled. I've searched my entire system for cron files that might be related to this and found nothing.

Suggestions:
  • First of all, I'd say don't use cron. Anything it can do launchd can do better, and the files are in standard user-visible locations and more readable.
  • If you're still using cron, please check for stray entries such as the one that I'm seeing. I'd delete it myself except I can't find the thing.

In researching this, I was a bit appalled at the potential for breakage in the "backup-on-mount" system.
  • Two different launchd scripts watch for either login or /Volumes events
  • They launch an alias in the home directory that's to a script located inside the SuperDuper application bundle
  • The script does some diskinfo magic and jury-rigs some plists for Tiger users, seemingly to get a list of what disks are attached.
  • Script then iterates through all scheduled copies in the user's home folder looking for ones that run on mount, and if they contain the newly mounted drive name. What if I have two backup-on-mount destinations called "Backup" and "Backup 2"?
  • If found, environment variables are set and a new application (which appears to be inside the scheduled copy package) is launched which will launch SuperDuper and the scheduled copy. Not sure why an app is needed for this; just script it since you're already in AppleScript.
It requires two launchd scripts, an alias to resolve, is dependent on the workings of a command-line program which has changed format in the past, assumes disk layout is in a standard state (e.g. home directory hasn't moved), then is dependent on the internal XML of the scheduled copies, assumes disk names won't contain other disk names, sets an environment variable that only this one app knows, and fires the app. :eek:

Code:

launchd (2) -> alias -> AppleScript -> diskinfo (10.4 vs 10.5) -> iterate through folder (hope it didn't move, parse XML) -> set environment variable -> open a buried ".app" -> open SuperDuper.app
Suggestion:
  • Use a single launchd daemon that runs on either login or on /Volumes changing.
  • Use a single AppleScript or compiled daemon in a known location (/usr/local/bin is traditional), which at the end calls SuperDuper directly with the appropriate parameters.

My attempts at replacing this system have been difficult, as SuperDuper's "error" keyword in AppleScript conflicts with the language itself and can't be used:

Quote:

status (idle/running/done/error, r/o) : Returns SuperDuper's current status
"Error" is reserved by the AppleScript language:

Quote:

error
Signals an error in a script.
Syntax
error [ errorMessage ] [ number errorNumber ] ¬
***[ partial resultresultList ] ¬
***[ from offendingObject ] [ to expectedType ]
I get as far as checking volume mounts, ensuring the necessary volumes are there, put up a brief message, and get all the way into telling SuperDuper to copy - and then get stuck on the error status. So instead of checking for an error you have to check all other statuses and from that figure out there was an error. Kludgy.

Suggestion:
  • Use something not reserved by AppleScript. :)

dnanian 03-13-2010 06:39 PM

Needless to say, SuperDuper!'s scheduling facility is older than launchd, and there's little reason to move from cron to launchd: it doesn't do this kind of thing "better", it's just "newer". (In fact, cron's been around for a very long time, and is well known and tested.)

If you want to edit the crontab, you can use "crontab -e" and remove the bad entry... but I don't know how you ended up with a 'stray'.

As far as "Backup on Mount" goes, I'm well aware of how it works, and I think you'll find it's less fragile than you imply. To make things easy to remove, all executables (etc) are kept in user accessible areas - /usr/local/bin, while traditional, is not removed when the application is removed (and the alias is updated to point at the right place each launch).

Two destination called "Backup" and "Backup 2" aren't a problem, because the actual full volume name is checked once a quick pass is made to subset the settings being tested. And we don't duplicate the functionality in the schedule driver because, well, why maintain two executables that do the same thing?

Also, we can't use one launchd daemon: it doesn't work properly in all versions of OSX.

Alas, I know about the "error" thing - it's a known, logged issue (you're the first person other than me to notice, so kudos).

diamondsw 03-14-2010 05:36 AM

Quote:

Originally Posted by dnanian (Post 28945)
Needless to say, SuperDuper!'s scheduling facility is older than launchd, and there's little reason to move from cron to launchd: it doesn't do this kind of thing "better", it's just "newer". (In fact, cron's been around for a very long time, and is well known and tested.)

It's also deprecated and could be removed entirely any time. Launchd is much more flexible, and in my opinion (but just an opinion) more readable and readily accessible than cron. Cron's advantage is it's familiar... to people who know cron. I thought I knew cron, but vixie-cron is quite a bit different from the traditional editing of /etc/crontab.

I'd have also thought that with the backup-on-mount system using launchd and Applescript, it would make sense for the scheduling system to also use the same framework. What exactly does cron allow SuperDuper to do that launchd does not?

Quote:

Originally Posted by dnanian (Post 28945)
If you want to edit the crontab, you can use "crontab -e" and remove the bad entry... but I don't know how you ended up with a 'stray'.

SuperDuper is the only thing accessing it. So, I don't know what to tell you. :confused:

Quote:

Originally Posted by dnanian (Post 28945)
As far as "Backup on Mount" goes, I'm well aware of how it works, and I think you'll find it's less fragile than you imply. To make things easy to remove, all executables (etc) are kept in user accessible areas - /usr/local/bin, while traditional, is not removed when the application is removed (and the alias is updated to point at the right place each launch).

I'd hope you know how it works! :-) Still, I can't help but think that there's got to be a fair amount of code in there devoted to keeping the various parts of that working and checking for errors that wouldn't necessarily be required with a simpler setup. It's an awful lot of glue to accomplish:
  1. Check for a new mount.
  2. Check if a backup script references it.
  3. Run backup script(s).

I suppose when you get down to it, the things I don't understand are the need for two launchd agents instead of one, and the opaque ".app" that starts things rather than just scripting SuperDuper directly. The alias I'm more comfortable with, as I can see that gives a stable path for the launchd agent and alleviates the concerns about moving SuperDuper.

Quote:

Originally Posted by dnanian (Post 28945)
Two destination called "Backup" and "Backup 2" aren't a problem, because the actual full volume name is checked once a quick pass is made to subset the settings being tested.

Good to know, thanks.

Quote:

Originally Posted by dnanian (Post 28945)
And we don't duplicate the functionality in the schedule driver because, well, why maintain two executables that do the same thing? Also, we can't use one launchd daemon: it doesn't work properly in all versions of OSX.

The devil's advocate in me says, then why maintain the multitude of pieces that currently backup on mount and schedule copies? There are so many bits of Applescript, stub applications, and command line utilities, whereas I'd think Launchd could handle the events, and at most a single daemon or script could handle passing control to the main app. I know it's grown over time - especially working around OS differences - but it still just seems overwrought.

I suppose when you get down to it, there's no arguing with results - the only issue I have is this phantom cron entry; backups run just fine - and your user base would likely agree that all is well. Something just feels off, and when I see that many pieces, I naturally worry about breakage. The more complex any system is, the more likely it is that something can fail. Of course, given your intimate work with filesystems, you know about that with far, far more experience than I - I've read the travails on your blog.

Quote:

Originally Posted by dnanian (Post 28945)
Alas, I know about the "error" thing - it's a known, logged issue (you're the first person other than me to notice, so kudos).

Heh, pretty sure I reported this one back in the day (2.0 era) when I first created my own scheduling script. I'd still use it, but my backup routine is now much more based on Time Machine for continuous backup, and backup-on-mount for occasional bulk backups to offline storage.

dnanian 03-14-2010 10:58 AM

Cron is not deprecated (see "man cron" - no menton of deprecation): in fact, it's implemented with launchd. Launchd doesn't offer any more flexibility for timer-scheduled events (I had hoped it would, but it doesn't). Rewriting scheduling to use launchd wouldn't really generate any tangible benefits, other than to use "the new shiny". There's just no compelling argument to do so at present.

As far as vi goes, well, navigate to the line you want to remove with the cursor keys, press 'd' twice to delete the line, then ":wq" to write and quit vi. Alternatively, if you uncheck the time part of all your schedules and then use "crontab -r", it'll remove the tab. It'll then get recreated when you turn the schedules on again.

The two daemons - that is, the login one and the 'on mount' one - do entirely different things. One sets up the backup-on-mount environment by initializing the list of volumes, which handles situations like logging in and out of an account where temporary items aren't removed. One actually responds to mount events. They're quite different, even though they call the same program (with different parameters) to do the actual work.

I just don't agree that this stuff is overly complex. Each part is there for a reason... there's an 'automatic run' driver that's used to run a given set of settings for an event (either scheduled, on mount, on button press or any other event), there's a system tool for running on schedule that we leverage (and was there well before launchd, and offers the same functionality with the same limitations), and there's launchd for triggering running on mount.

Each group of settings has its own 'automatic run' driver because they're designed to be modifiable by advanced users on a 'per setting' basis. You need a separate backup-on-mount 'driver' because you don't know where the 'automatic run' driver is when the event fires (and there can be many), nor what settings should be used, and that takes an event ("something mounted") and that determines how to respond to the event, and with what.

Yes, we could put all that not-really-that-related-but-working-together-to-accomplish-a-task logic in one giant centrally-located tool, and eliminate the user-modifiable part, but that gets rid of useful functionality (to a small number of users, of course), and doesn't really 'fix' any problem (and, it couples things closer than I would want). I mean, it'd be like taking every command-line tool in Unix that deals with 'files' and combining them into one huge tool with a zillion parameters to 'streamline maintenance'. They tried that in CPM: it was called 'pip', and it was a huge mistake.

(As an aside, this stuff is done in AppleScript, rather than in Objective-C, to show how you can use AppleScript to accomplish system-level things in OS X. Personally, AppleScript drives me crazy—I can't tell you how much I struggled with it when I wrote these two parts—but it's more understandable than the various shell script languages to most users, and was the right tool for the job.)

Anyway, things sometimes feel 'off' when you haven't gone through the process and history of creation. Does that mean everything in SuperDuper! is perfect? No - but there are usually good reasons to do what we've done...

diamondsw 03-14-2010 05:27 PM

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 03-14-2010 05:38 PM

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 03-14-2010 07:45 PM

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

diamondsw 03-15-2010 10:06 AM

Quote:

Originally Posted by dnanian (Post 28951)
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:

Quote:

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 03-15-2010 10:58 AM

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 03-29-2010 12:46 AM

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:

Quote:

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 03-29-2010 08:53 AM

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 08-19-2012 09:24 PM

It's happened to me, too
 
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.

Drdul 08-19-2012 09:42 PM

Fixed it!
 
Well, that turned out to be easier than I expected. I must have been doing something wrong earlier, as I managed to find the leftover SD entry in my crontab, and as it was the only thing in there, I simply removed the crontab.

dnanian 08-19-2012 09:53 PM

That'll certainly do it... :-)


All times are GMT -4. The time now is 08:11 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.