Sorry about the confusion: The reason why I created two separate scripts was to force the copying to happen after the wget downloading was finished.

In my original script, I had both downloading (wget) and copying (cp) in the same script, and the described events happened when I ran this script first in a terminal and then as a launchd job.

Please reply if it is still unclear.

As you understand, I solved my problem by creating two separate scripts, but I find it very odd that this happens.

At the moment, the problem with disappearing jobs after reboot is more important for me to solve.

I also have to ask one question. Is there any reason you aren't running these scripts on the server locally via cron? I just think it is more efficient. My hosting company does daily tape back ups of my webroot and home directory on their server. I have a cron job that dumps mysql into a back up file and another one that archives all files and tosses it into another directory in my home folder on my server.

that way I have back ups and they have back ups of my back ups and I don't have to worry about maintaining that many back ups on my own. Plus, if WAN traffic is down somehow between your client machine and your web hosting server, your scripts won't even run.

Most hosting companies also provide tools for this built in.

So, is there a reason you have to do it this way?

@tlarkin: That's a good point, I might be able to run the script on the server.

To keep all the backups on the server is not a solution, though, as I'll quickly run out of space. So I do need to download it to my computer at some point.

My hosting company does backup my site nightly, but I want to see what files changed when, to make it easier to rollback the site to the state it was before a specific accident happened.

I understand, you can have them save date stamped files then set cron to only keep the 30 days worth of back ups, so when day 31 hits it erases day 1 back up, then when back up 32 hits back up 2 is erased and so forth.

However, you can have them rysnc to your FTP at home on a daily basis and that way everything is ran off the server and not your machine. Launchd items will take up cpu cycles.

rsync is not installed on the server. I'm pretty sure I tried using rsync before (which I think requires rsync installed on both host and recipient). That's why I ended up using wget instead.

Anyway, I had some hope of learning to use launchd, but it seems it is tricker than I first imagined. My mac mini doesn't do much during the day except serve torrent files and store backups from my other computers, so I don't really mind some CPU time for this backup script.

Not sure about your host, but if you aren't the admin of it you can request it be installed and aliased in your bash profile. I requested they install cron for me and they did.

I don't think I can be bothered to get my host to install rsync and then recreate the script to work on the server. My script is very close to do what I want it to do, I just need to figure out how to reload my launchd jobs after reboot.

that is easy, launchctl -w load /path/to/agent, the -w switch makes it load permanently.

Solution: Place the job files (backup-download.xml and backup-copy.xml) in the folder ~/Library/LaunchAgents

After a reboot, both jobs are loaded in launchd, visible by running this command:

@tlarkin: You beat me to it. Your solution enables me to keep all the files in the same place as well, which I like.

launchd items run on several levels from several locations. The first two are:

1) /Library/LaunchAgents

2) /Library/LaunchDaemons

If your agent is loaded into #1 it will load when any user logs into the system. If you put it in #2 it will load at boot up globally with out any user logging in. Both of these run globally, either by log in or just at boot up.

The other place you can load them from is:

~/Library/Launchagents

These are located in the specific user's home folder and they run only when that user logs in.

If you launchctl to load your agent with the -w switch it loads it in launchd permanently, meaning every time you reboot or log in, it will run.

That's great, thank you.

I cannot get the -w option to work, though. The man page says this:
I don't understand what that means, but as far as I can tell, the jobs are not reloaded after reboot.

If I place the job files in ~/Library/LaunchAgents, they are reloaded after reboot, though.

Where are you placing the launchd items at? They have to be placed in one of the three directories I listed in my above post.

Ok, sorry, then I misunderstood.

I thought the -w option meant I didn't have to place them in one of the 3 folders. If I place them in ~/Library/LaunchAgents I don't have to use the -w option to get them to reload after reboot. On my mac, my user is logged in automatically on reboot, if that matters.

I ended up using hard links, so I could still keep the xml files in the same folder as the script and backup files.

To create a hard link for the file backup-copy.xml:

Yeah, all the -w switch does is tell launchd to keep running that agent according to where it is at. For example, you would place all your log in hooks at /Library/LaunchAgents or ~/Library/LaunchAgents, since launchd runs them at log in.

Thanks. Now it works. Relief :-)

Well if you want the exciting apple official white page on launchd, here you go. I have read over it a few times, and it never gets that interesting but it does make you understand how launch agents work

http://developer.apple.com/MacOsX/launchd.html

You can accomplish some really powerful solutions with launchd. I have created several post config one time run scripts in my images, so the second it boots up, it runs the script then the script deletes itself along with the launch item so it only runs once at first boot and never again. Great way to automate post image configurations on the Mac platform.