From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 19:34:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 970D5106564A for ; Tue, 27 Apr 2010 19:34:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 7E37E8FC18 for ; Tue, 27 Apr 2010 19:34:04 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L1J001G4VOQJ580@asmtp026.mac.com>; Tue, 27 Apr 2010 12:34:04 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004270164 From: Chuck Swiger In-reply-to: <20100426085947.GB20779@megatron.madpilot.net> Date: Tue, 27 Apr 2010 12:34:01 -0700 Message-id: References: <20100426080815.GA41938@icarus.home.lan> <20100426085947.GB20779@megatron.madpilot.net> To: Guido Falsi X-Mailer: Apple Mail (2.1078) Cc: "freebsd-net@freebsd.org Net" , freebsd-rc@freebsd.org Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 19:34:06 -0000 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 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