quack quixote's questions

I've got a script that gets run during boot on a Debian server. It's getting run too early, but I can't control when it's fired off. I can force the script to delay its own run with:

sleep 60

...or, alternately, I could just try the action a few times, like this:

TESTRUN=0
ACTIONWORKED=0
while [ $ACTIONWORKED -eq 0 ] && [ $TESTRUN -le 5 ]; do
      # run the action i want
      # quick test if it worked
      # if yes, set ACTIONWORKED=1
      # if no, sleep 10
      # increment TESTRUN
done

What's a better way to test that the system is ready? The script will be run at other times during system operation, so the test is needed to differentiate between "booting-can't-do-this-yet" and "not-booting-run-now" states. I don't want it to wait every time the script runs.

Edit: Thanks for the ideas so far. Keep 'em coming if you have alternatives to what's already been posted.

To those who've asked for specifics, I've left them out of the question specifically to gather answers that work with the general Linux boot process.

Assume a "fully booted" system has presented a login prompt (via console, X, or whatever).

I'm creating UDEV rules for automounting external drives on a headless server, much in the same way as Gnome-VFS does automounting during a user session.

I'm concerned with the rule's behavior at boot-time. There's a good chance one of these drives will be connected during a boot, and I'd prefer any connected drives get mounted in the right place. The drives might be either USB or Firewire, and they are mounted from a shell script fired off by UDEV on detecting an "add".

Here are my questions:

1. When UDEV runs the mount for these devices at boot, will the system be ready to mount it? Or will the script get triggered too early?

2. If it's too early, what's a good way for a script to tell that the system isn't ready yet (so sleep a while before checking again)?

3. The UDEV rule matches ACTION=="add". Does this event even fire at system boot?