Ask Different is a question and answer site for power users of Apple hardware and software. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a simple backup shell script that runs daily at 1:00 AM. It uses rsync to copy twelve different directories onto my Windows computer's external hard drive. Here's an example:

rsync -a --delete-after --progress --stats "$HOME/Downloads" "/Volumes/Backups/MacBook Pro"

It used to work fine, but one day it kernel panicked. Then the next day. And then the next. I did some troubleshooting and found that the kernel panic only occurs when the "$HOME/Documents" directory is included in the list of directories to be backed up. But here's the bizarre thing: if I run the backup script manually, the script makes it all the way through without a kernel panic. Any ideas? Here's the report:

Sat Jun 23 01:05:10 2012
panic(cpu 4 caller 0xffffff80002c473a): Kernel trap at 0xffffff7f8081a348, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0xffffff802216a000, CR3: 0x00000001c4fd3077, CR4: 0x00000000000606e0
RAX: 0x0000000000000067, RBX: 0xffffff802216005c, RCX: 0xffffff801dee780a, RDX: 0x0000000000000000
RSP: 0xffffff80f05cbb60, RBP: 0xffffff80f05cbbc0, RSI: 0x0000000000000001, RDI: 0xffffff8022169fcc
R8:  0x0000000000000000, R9:  0x0000000000000000, R10: 0x80000001c4fd3077, R11: 0xffffff8023ffc800
R12: 0xffffff802216a000, R13: 0x0000000000000002, R14: 0x000000000000805c, R15: 0x0000000000000034
RFL: 0x0000000000010296, RIP: 0xffffff7f8081a348, CS:  0x0000000000000008, SS:  0x0000000000000010
CR2: 0xffffff802216a000, Error code: 0x0000000000000000, Faulting CPU: 0x4

Backtrace (CPU 4), Frame : Return Address
0xffffff80f05cb810 : 0xffffff8000220792 
0xffffff80f05cb890 : 0xffffff80002c473a 
0xffffff80f05cba40 : 0xffffff80002da0cd 
0xffffff80f05cba60 : 0xffffff7f8081a348 
0xffffff80f05cbbc0 : 0xffffff7f807fd83b 
0xffffff80f05cbc60 : 0xffffff7f807fd8fe 
0xffffff80f05cbcc0 : 0xffffff7f80804bd9 
0xffffff80f05cbd00 : 0xffffff80003192d0 
0xffffff80f05cbd30 : 0xffffff8000308911 
0xffffff80f05cbf50 : 0xffffff80005cd61b 
0xffffff80f05cbfb0 : 0xffffff80002daa13 
      Kernel Extensions in backtrace:[82526DF2-3BDB-3898-BA94-F58C5D4E0E01]@0xffffff7f807f2000->0xffffff7f80826fff

BSD process name corresponding to current thread: rsync

Mac OS version:

Kernel version:
Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64
Kernel UUID: A8ED611D-FB0F-3729-8392-E7A32C5E7D74
System model name: MacBookPro8,2 (Mac-94245A3940C91C80)

System uptime in nanoseconds: 252434098601163
last loaded kext at 236423088215259: net.tunnelblick.tun    1.0 (addr 0xffffff7f80791000, size 32768)
last unloaded kext at 236897483051934: net.tunnelblick.tun  1.0 (addr 0xffffff7f80791000, size 24576)
loaded kexts:
org.virtualbox.kext.VBoxNetAdp  4.1.10
org.virtualbox.kext.VBoxNetFlt  4.1.10
org.virtualbox.kext.VBoxUSB 4.1.10
org.virtualbox.kext.VBoxDrv 4.1.10 1.7.2  1.9.5d0  1.59    122    3.5.9   1.0.26   2.2.0f3   2.2.0f3   7.1.8   100.12.42   7.1.8    3.0.2d6   5.0.0d0  1.0.0d1    4.0.5f11   7.0.0 1.2.2    2.0.1d2    3.0.16    5.0.0d0    7.1.8   1.5.8    3.0  4.0.5f11  225.2 225.2  312 1.0.0d1 1.0.0d1 33  3.2.0 404   2.0.3  2.0.3  1.2.0    4.5.0    4.8.9   530.4.20    3.1.2b2  1.5.0  2.3.0   161.0.0   4.5.8   1.5   1.5  1.6    1.8    1.5  1.5 193.0.0   3.2.30   1.3   193.0.0 2.2.0f3   1.0.10d0   80.0.2  10.0.5    2.2.4   1.8.6fc17    1.3 2.2.0f3 2.2.0f3 3.0.16   3.0.16   3.1.3d8 5.0.0d0  1.0.10d0 5.1.0d17   1.0.3   2.3.2 1.0    7.1.8   7.1.8    7.1.8    2.3.2 4.0.5f11   4.0.5f11    1.8.2    1.8.2 1.2.4 227.1  4.4.5   4.5.3  4.5.8    182.11.0  3.2.0   1.6  1.7   1.7   3.2.0    1.5.5 2.0.0 4.5.8    4.4.5   420.3 1.0.1b1  2.1    2.0.8 4.5.8    1.5.0 1.7.1   1.1  177.5   1.0.0d1  7 331.6 1.7.1  28.18  1.5 2.6.8    1.4

EDIT: Here is the shell script I'm running:


target_directory="/Volumes/Backups/MacBook Pro"

    "$HOME/Pictures/Photo Booth Library"
    "$HOME/Library/Application Support/Firefox"
    "$HOME/Library/Application Support/TextMate"

if [ -d "$target_directory" ]; then
    for directory in "${directories_to_back_up[@]}"
        if [ -d "$directory" ]; then
            echo "The following backup will begin in 10 seconds:"
            echo "Source: \"$directory\""
            echo "Target: \"$target_directory\""
            sleep 10

            rsync -a --delete-after --progress --stats "$directory" "$target_directory"
            echo "The following directory was not found:"
            echo "\"$directory\""
            echo "Therefore, it was not backed up."

        echo "----------------------------------------"
    echo "The backup could not proceed because the following directory was not found:"
    echo "\"$target_directory\""
share|improve this question
How is the script invoked, 1. manually, 2. on schedule? In other words which exact command is used to start, and how do you schedule running the script? – Pro Backup Jun 28 '12 at 16:33
@ProBackup It's just a cron job: 0 1 * * * /Users/Nick/Documents/ I run it manually using the same command. – Nick Jun 29 '12 at 2:05
what is the content of the file? Why use cron when launchd is the preferred mechanism in OS X (at least since 10.6) for launching scheduled tasks? – Pro Backup Jun 29 '12 at 8:56
I would start trying to launch the script via launchd using a user daemon job. Create the plist file. When job needs to run even when no users are logged in put it in in /Library/LaunchDaemons/. Two, $ sudo launchctl load -w /Library/LaunchDaemons/my.scheduled.backup.plist. There is a nice plist cron style example at… Note: Before editing the plist, unload it first. Then load it again after your edit is ready. – Pro Backup Jun 29 '12 at 9:18
Sorry that I can't answer and have to ask an additional question. Under which user account does your cron (job) run? Most likely root, but to be sure, that is why there is a difference between running as cron job and running the script interactive from your shell. – Pro Backup Jun 29 '12 at 19:24

I notice you have VirtualBox kexts loaded. I assume you have a VM running during the backup. In the past few months I've had kernel panics (nowhere near consistent as yours), from varying apps, but I eventually realized they only happen if I have VMs running and a high CPU load (like rsync would create).

I have no idea why yet, but you could probably test that on your system.

Your rsync command looks OK. I second the comment that says you should use launchd rather than cron though. Cleaner, more reliable, and once you create the plist in the right place, you won't have to worry about accidentally running as root.

There's a nice app called Lingon that provides a GUI for launchd. Very nice to work with, even if you're comfortable editing plist files manually.

Also, make sure the shell you specify at the top of the script is the same as the shell you're using in Terminal. Doubtful that's it, but you never know.

share|improve this answer
I actually don't have any virtual machines running during the backup. I haven't used launchd before, but, to experiment, I commented out my cron job, put a plist file in ~/Library/LaunchAgents, and loaded it with launchctl. We'll see what happens. I'll report back. Thanks for your time! – Nick Jul 1 '12 at 3:08
Having the script run via launchd didn't prove to make any difference. I ended up fixing the problem by deleting a folder full of icons (I think there were around 18,000 or something crazy like that). I don't think there was anything about the icons themselves causing the problem. I think it was just the fact that rsync was dealing with so many files. Still, it seems strange that this would happen. Any other thoughts? – Nick Jul 10 '12 at 2:28
The backtrace contains the kext - this is the kext for connecting to samba/windows network shares. If the backup destination is such a network share, I could imagine that you've found a bug in handling more than X thousand files on a windows share. – pmdj Aug 4 '12 at 19:27
@pmjordan The only flaw in that theory is that the script worked fine when run manually – Nick Oct 11 '12 at 3:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.