September 2005 - Darwin-dev

Re: Replacing launchd
by Graham J Lee 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) Actually, I think your points are apt. I have started to think that it should be something like this: http://nextstep.sdf-eu.org/launcharbiter.tar.bz2 Cheers, Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Dave Zarzycki wrote: A new tool written explicitly to interpose the execution of any program would be far more useful. I'm thinking of shell scripts and whatnot. but obviously with a user-definable policy, which I haven't implemented yet, and slightly more in the way of policy settings ;-) The plan at the moment is for global policy modified by per-basename dictionaries... This email sent to site_archiver(a)lists.apple.com

1 0

Re: Replacing launchd
by Dave Zarzycki 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Sep 30, 2005, at 1:16 PM, Graham J Lee wrote: Actually, I think your points are apt. davez _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Therefore I strongly agree with absolutely everyone, I think, except where I disagree :-). Taking the combined paths of least surprise for sysadmins and least pain for devs/maintainers, I'm of the opinion that a completely independent policy engine - so more like tcpd and less like launchproxy - is the way to go; it also would have the benefit to those admins who aren't fully launchd'd yet that as it wouldn't care about launchd, it could be used with init, SystemStarter, cron et al. A new tool written explicitly to interpose the execution of any program would be far more useful. I'm thinking of shell scripts and whatnot. If Apple chooses to spend resources on writing such a tool, I will try and push for it to be more generic than a launchd feature item. :-) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Replacing launchd
by Graham J Lee 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) Cheers, Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Jordan K. Hubbard wrote: As you yourself have noted, the tcpd utility is a good example of a policy engine which interposes itself in between the launch criteria ("incoming request on port 21!") and access control policies that the jobs themselves know nothing, and should know nothing, about. It sounds like this "launchproxy" tool of yours simply needs to grow some additional knobs and also perhaps reintroduce the notion of a scripting language which we had at the end of Tiger but kicked out of launchd (for good reasons). That would give the users/admins what they want and you the abstraction layers that you want. We can't just expect everyone to roll their own, however. That will only stand in the way of launchd's adoption since admins don't want to do that, they just want to get their work done. I largely agree with you Jordan, although if the goal is to have an intermediate policy engine between launchd and its jobs, launchproxy isn't quite that because launchd "knows" about launchproxy, and decides whether to invoke it (see job_start_child() in launchd.c). Compare with the tcpd model, where xinetd (say) neither knows nor cares what tcpd is or whether a particular request is serviced by a "real" daemon or by tcpd. The daemon which eventually runs, e.g. telnetd, also neither knows nor cares what tcpd is nor whether it is now running because it was execv()d by tcpd or whatever. If an admin misconfigures tcpd then it breaks those things the admin has chosen to invoke via tcpd, nothing else. OTOH if the mooted über-launchproxy were misconfigured then it would break any job which launchd - not the admin - has invoked via launchproxy. The way I originally implemented my change by extending the corpus of launchd's XML keys didn't quite achieve the above "only when I want it" aim, but only because I was thinking in perl mode - it would have been possible to only travel the power-checking code path if such had been requested. And as Dave correctly pointed out even it were an independent policy choice from the PoV of an admin it certainly wasn't from the PoV of anyone who has to maintain a launchd code tree (of which Dave is a shining example :-) as the additional code complexity and dependencies are passed on to launchd, not confined to the bit of code in charge of policy. Therefore I strongly agree with absolutely everyone, I think, except where I disagree :-). Taking the combined paths of least surprise for sysadmins and least pain for devs/maintainers, I'm of the opinion that a completely independent policy engine - so more like tcpd and less like launchproxy - is the way to go; it also would have the benefit to those admins who aren't fully launchd'd yet that as it wouldn't care about launchd, it could be used with init, SystemStarter, cron et al. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Replacing launchd
by Jordan K. Hubbard 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Replacing launchd
by James Berry 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/james%40jberry.us This email sent to james(a)jberry.us _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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(a)lists.apple.com

1 0

Re: Replacing launchd
by Dave Zarzycki 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Sep 30, 2005, at 11:39 AM, Graham J Lee wrote: Woot. Glad to hear it. :-) davez _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Dave Zarzycki wrote: 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... ;-) Ya, I think if Apple does anything in this feature realm, it'll be in something much like tcpd. :-) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Replacing launchd
by Dave Zarzycki 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Sure, You could modify that if you wanted. In fact, that is probably the best approach. davez On Sep 30, 2005, at 11:33 AM, Peter Seebach wrote: For all of these reasons, I don't see limits like this being added to launchd any time soon. -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… The launchd project already has a "launchproxy" tool that is used for inetd emulation. In message <F2FC13CE-2288-4787-9F8D-0E0B0591301B(a)apple.com>, Dave Zarzycki writ es: Perhaps the solution could be an intermediate thing that launchd runs which determines whether to really run its job or just sleep? This email sent to zarzycki(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Replacing launchd
by Graham J Lee 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) Cheers, Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Dave Zarzycki wrote: 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... ;-) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Replacing launchd
by seebs＠plethora.net 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com In message <F2FC13CE-2288-4787-9F8D-0E0B0591301B(a)apple.com>, Dave Zarzycki writ es: >For all of these reasons, I don't see limits like this being added to >launchd any time soon. Perhaps the solution could be an intermediate thing that launchd runs which determines whether to really run its job or just sleep? -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Replacing launchd
by Dave Zarzycki 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Sorry, davez On Sep 30, 2005, at 8:49 AM, Graham J Lee wrote: Cheers, _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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: 1) If it isn't OK to run now, then when? Should it just be skipped, or delayed? 2) Pathological cases. What if the laptop is always on battery when awake and asleep when charging the battery? 3) A slippery slope. This change adds two new libraries to launchd's link line. I've seen other requests to monitor other frameworks to provide limits like this (the SystemConfiguration framework for example). We could easily end up with launchd linked against dozens of frameworks on the system. launchd is too fundamental to the system to be risking linking against so many libraries. 4) Given the above problems, and the fact that people eventually want other limits, we're faced with the inevitable desire to have some language to express the limits. Linking against an interpreter is arguably a layering violation for something as fundamental to the system as launchd. It certainly provides for an explosion of complexity and therefore risk for launchd. Why? launchd is a single- threaded state engine, therefore any misbehaving script would hang launchd. Sure the scripts could be put on their own threads, but at that point, why not have a full blown process managed by launchd? For all of these reasons, I don't see limits like this being added to launchd any time soon. Dave Zarzycki wrote: On Sep 29, 2005, at 3:57 PM, Graham J Lee wrote: OK, well if it *will* work then I'll get on to testing. I suppose I was unjustly worried - even if WindowServer doesn't come up properly then at least getty ought to.... Just remember, Command-S will boot you up into single user mode, where you should be able to fix most mistakes. Failing that, you'll need a second partition or disk to boot from to undo mistakes. Thanks. As it turned out I didn't need to be so paranoid - it worked well. This iBook is now running a variety of launchd which will not run a job if NotOnBattery is true and the system is found to be powered from the battery. There's a patch at Radar# 4281025 and at http://bugzilla.opendarwin.org/show_bug.cgi?id=5200 (which I've assigned to myself - I don't know whether that's what I was supposed to do but as I'd fixed the bug I guessed it was ;-). Graham. This email sent to site_archiver(a)lists.apple.com

1 0