Ouch, just figured it out, I will load a launch daemon just before exiting. This daemon will call the script.

You could also use "trap" in each script which is a shell builtin.

#!/bin/bash



# Define a function to call for the trap

OnExit() {

    run script

    # or execute policy

}



# Tell the script to call the function when an exit signal occurs

trap OnExit exit



# Do the script's stuff

do a command

do a command



# Now on exit it will always trigger the above function

exit 0

I have more fleshed out examples in a post I did here:
http://bryson3gps.wordpress.com/2013/11/10/bash-favorites/

Adding an ampersand at the end of a line in a script will run that process in the background and should allow your new forked process to continue although your script is exited.

#!/bin/sh

    run stuff in your script

    sh /path/to/another/script.sh &

exit 0

A downside to this method is you can't easily return any results to the JSS from the forked process.

Did something change with Bash or the way the JSS runs scripts? I cannot for the life of me get a thread to fork or a trap to execute on exit without Casper waiting for it to complete while I am trying to schedule a restart, which means the policy log never gets uploaded to the JSS (the restart interrupts it). My tests work fine outside of Casper.

I am thinking a launchdaemon is my only option. I would use a policy-driven restart, except the restart occurs even if the policy fails, which is very bad for my needs.

I moved a lot of postinstall stuff into running out of launchdaemon just for that express reason that the casper policy finishes successfully, and what I need to happen at the back end finishes. I usually have my recon built in the postinstall if I need the database updated as well.

Yeah, I just built a launchdaemon to run a script for my reboot, and that solved it.