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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[email protected]"
