site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Sep 30, 2005, at 11:39 AM, Graham J Lee wrote: Dave Zarzycki wrote: [...] Cheers, Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/james%40jberry.us This email sent to james@jberry.us _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Today, launchd's operating goal is to find *any* reason to run a job and run it. launchd tries hard to stay out of the business of providing policy mechanisms like this for multiple reasons: For all of these reasons, I don't see limits like this being added to launchd any time soon. Oh well, I scratched my itch, learned stuff about the way OS X works in the process, and modified the behaviour of my system to better suit my usage. So I'm happy :-) As Peter Seebach wrote, perhaps a separate policy wrapper - analogous to tcpd for network services - is the way that should "really" go. Oh dear, I'm already considering firing up Xcode again... ;-) You might look at daemondo (of which I'm the author) which is part of the darwinports code (cvs HEAD). Its purpose is to function as an intermediary between launchd and your daemon of choice. It already links against SystemConfiguration, and friends in order to provide various processing for network and power states. You might look at extending this to provide anything additional you need. It knows how to execute various commands in response to various stimuli. This email sent to site_archiver@lists.apple.com
participants (1)
-
James Berry