rc(8) script -- waiting for the network to become usable

[Chuck Swiger]

Hi, all--

On Apr 26, 2010, at 1:59 AM, Guido Falsi wrote:
> Regarding launchd, I don't know much about it, but I do like the rc
> system and having the boot sequence managed by scripts one can easily
> modify to taste. I'd rather not modify this system with some daemon
> performing obscure tasks based on some configuration file. The
> flexibility given by scripts is imho, quite superior to any configurable
> daemon's.

Launchd is intended to replace the combination of init, rc startup scripts, (x)inetd, and cron/at.

People who are happy with the traditional Unix distinctions between all of above (and/or do not care for XML plists) may not be fans of launchd.  If you're using a Unix box in the traditional role of a server which is always on with permanent Internet connectivity, these traditional Unix mechanisms work just fine.  Launchd is intended to deal with the opposite conditions (although it also works okay for permanent server roles, too); ie, it has scheduled jobs, but it will run ones which didn't execute at a particular time because the machine was asleep via StartInterval or StartCalendarInterval:

     StartCalendarInterval <dictionary of integers or array of dictionary of integers>
     This optional key causes the job to be started every calendar interval as specified. Missing argu-
     ments are considered to be wildcard. The semantics are much like crontab(5).  Unlike cron which
     skips job invocations when the computer is asleep, launchd will start the job the next time the com-
     puter wakes up.  If multiple intervals transpire before the computer is woken, those events will be
     coalesced into one event upon wake from sleep.

It also includes the notion of whether the machine has working network connectivity as an explicit condition which jobs can use to determine whether they should run or not.  Wandering around with a laptop as you go into and out of range of wireless networks is a case which tends to require significant interaction from someone with root access to the box to restart things which should have gone down when there was no network and are in a silly state, whereas it's handled reasonably well by launchd-controlled stuff via KeepAlive / NetworkState:

  http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man5/launchd.plist.5.html

I'm not in love with launchd, or XML plists, either, but it comes closer to resolving issues of running stuff on demand, keeping track of what's actively being used (and should be given a SIGTERM to have a chance to shutdown cleanly rather than a SIGKILL), tracking what needs to run under limited contexts (chroot, non-root userids, setrlimit() stuff, what has access to things like the window system or login window contexts, etc) than the alternatives do.

For example, the /etc/rc.subr mechanism supports chroot & non-root users fine, but has no way I'm familiar with to indicate that something maybe should not be running if nobody is logged into the machine and it is sitting at xdm, gdm, or whatever's login screen.

Regards,
-- 
-Chuck