Concept advice: abandoning a process

Question

I'm following Apple's guide from the Developer Connection to make an Mac OS X "StartupItem". I don't want to scare off any non-developers; they can be more, but this instance is just a shell script that runs during boot, with a notable caveat: robustness and prompt completion are very important. A StartupItem becomes part of Mac OS X's boot--so much so that 'hanging script' = 'hanging boot'.
For clarity and modularity, all of my code is in little separate executable files. The "master script" that is the StartupItem just activates the handful of "sub-scripts" and exits. None of the sub-commands are boot-critical and some can take quite a while to finish, so I'd like to execute them from the "master script" but then immediately "abandon" them.
I guess what I'm looking for is some "best practices" advice on just how to go about this. Searching is hard when you don't know what to search for. I did read some linux script advice that seems relevant but it all seemed slightly off for my purposes at best, and gimmicky at worst (e.g. a nohup and an ampersand?). My gut says to keep it simple, even if it's overkill and do something like, say... line 'em up in "screen":
screen -dm /bin/bash /blah/fixsomestuff
screen -dm /bin/bash /blah/thishangssometimes
screen -dm /bin/bash /blah/thisscript_almost_always_haserrors
screen -dm /bin/bash /blah/thisshould_be_a_daemon-it_neverexits
"screen," in particular, seemed attractive as I'd be able to attach a terminal to a bad script's "screen" session for debugging. The sub-script names above are facetious, but not that far off. I do need to guarantee they cannot interfere with the overall boot.
Even ignoring "screen," is there something I don't know? Is this a bad idea? I have output-redirection within each sub-script; should I be doing it on the initial "screen" line (or some other way (or both))? The scripts do exit (they're not daemon-ic?), but even so... should I be approaching the whole thing differently?
Any warnings, stories, or advice appreciated.
Joel

Answer 1

Unfortunately I don't have time now to respond to all the ideas and questions posed. Thanks for the great posts! Just some first thoughts...
screen is great. I will not be using it for every sub-script as I'd initially posted (that was just an idea, not "the plan"). I will still need to use it for one task. Its a script I didn't write that pulls updates from several servers on our lan. It is easy to monitor while it is running but doesn't generate useful logs. Ignoring all the terminal-emulation brawn of screen as seen in its man page, screen allows lots of handy things. In this case, it allows:
The StartupItem sh script launches the ≈20 minute command in a detached screen session.
That sub-command is script-caliber (its compiled though) and doesn't have useful logs. Its old, on its way to deprecation, and not worth fixing.
If I suspect problems, I can log into the machine in an ssh, reconnect to the screen session and see all the live and past stdout/err of the command still in progress.
Is there a better way to do that?
My scripts always have shebangs. So do almost everyone else's scripts though... so why do I still see things like /bin/sh in shell commands in the wild? I've added /bin/bash to start bash scripts as a habit because I've seen full paths to shells in so many tutorials and examples. If given a script with a proper shebang, what's the difference between these?me$ /bin/bash /path/to/script
me$
me$ bash /path/to/script
me$
me$ /path/to/script
me$
me$ cd /path/to
me$ ./script
me$
me$ cd /path/to
me$ . script
me$
me$ exec /path/to/script
Back to my main structure concerns. None of my scripts are compiled nor are they daemons. Some take a long time, but they do exit. I just need the sh script that is the StartupItem to exit quickly, even if there were huge problems with the things it's starting. This is heavily truncated, but how does it look?#!/bin/sh
# /Library/StartupItems/dmeboot/dmeboot
# The old, compiled command with bad logging.
screen -dm /Library/Management/dmesyncprojlibs
# Both clean up garbage files from last user. FIX!
# Kludgy & no error handling. Often hang or exit non-zero due to files in use, etc.
/Library/Management/sessioncleaner &
/Library/Management/cumulativecleaner &
# wait a bit and add to rendering pool if nobody logs in
/Library/Management/checkin &
# ntpd controller, timecode interface
/Library/Management/dmentpd &...etc.
Out of time, not out of questions. Oh well, I'll post more later. Thanks again for reading or posting. Any thoughts or additional advice appreciated. Ciao for now, Joel