May 2006 - Darwin-dev - lists.apple.com

Re: StartupItems
by Michael Smith 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com seebs(a)plethora.net (Peter Seebach) writes: [speaking about disk arrival/departure detection] I'm not advocating polling models, there are callback models that suffice. In the short term I agree with you. You have some more work to do, but in the long term, this approach is sustainable and hopefully will not require further churn. Like, say, launchd? I think you've swapped ends here... That's a perfectly good question that deserves a few answers. I'd be surprised if there is not a platform specific line of code in your program. As a service provider, you advertise your services passively. As a service consumer, you attempt to consume said services. The latter results in the invocation of the former. No, the IPC mechanisms that launchd tunnels are generally ones that block on connection attempts. So clients can be completely unaware of launchd, or whether the service is always running or launched on demand. And servers only need to declare to launchd what their existing IPC mechanism is via a plist. They are? But by no means 99% of the services available on a Mac OS X system. = Mike _______________________________________________ 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… Wow. I can't actually say that I've seen such a collection of reactionary curmudgeonery in, well, a very long time. In message <5E024134-07E3-46B7-870D-268CB3D7ABB3(a)opendarwin.org>, Kevin Van Vec hten writes: Fair enough, but even MORE system-specific. Given that no other system you're going to touch with a ten-foot pole supports this in the first place, what do you expect? Freebies? As has been pointed out, on Mac OS and many other systems, disks come and go. If you are going to handle this at all, then you might as well accept that any volume other than the one you were loaded from may come and go at any time, in which case startup is just a special case. It's been a long time since the RA-81. You can actually pick a disk up and put it in your pocket, and this has changed the way people use them. You can't pretend that adding a new disk to the system must necessitate an electrician and a forklift anymore. [... continued ...] It may or may not. I just don't find myself convinced that every daemon in the world should acquire all this extra sanity-checking. I like to isolate repetitive tasks; I would rather see ONE program to dependency checking than DOZENS. Why should I care about OS X? It's imposing a totally new model on my code that contradicts how my code has worked fine on every other system for twenty years. Mac OS X has the largest installed base of any Unix-like operating system. Period. It's the only Unix-like operating system that takes the desktop environment seriously. Period. It's the only Unix-like operating system that is attempting to adapt the way that the system thinks about people, rather than the other way around. Period. There may be some, but there's damn little. I write portable, standard, code. And thus you get portable, standard, lowest-common-denominator behaviour. As has already been pointed out, if you want to act like a piece of code from the 1970s, that facility is available. There are good reasons not to, some of which are consequent on the points I just made above. But ultimately, the more I think about it, the more I think it's just plain wrong. Dependency checking is not something that should be duplicated in every program. I don't see your point; this is exactly what Dave & co. are asserting with the launchd service dependency design. Where is there any sort of "dependency checking" in the consumer, or for that matter in the provider? Earlier, you wrote: In message <a06010200c097a2d8ab74(a)[192.168.0.222]>, Peter Bierman writes: The obvious counterexamples are sockets and file access. Launchd will happily spoof local sockets, so I don't see a counterexample there. As previously noted, if by "file access" you mean "the presence of a magic file" then it's down to the vector that presents the file. If you're expecting it to arrive via filesystem mount, then DiskArbitration does everything you want and a great deal more. If you are talking about a passive or implicit rendezvous (e.g. waiting for a PID file before attempting to contact a local service by some other means), then you are typically looking at an arrangement that tries to avoid a problem that the launchd model has made obsolete. You can remove code in this case... should make you happier again. 8) Which are, by strange coincidence, 99% of UNIX services. My opening point about reactionary behaviour and obstinacy bears some restatement. As Dave and Kevin and others have pointed out here, the launchd architecture is trying to solve some fundamental, undeniable problems with the way that services are invoked and managed. To hear someone say "disk arrival is a user event and should be managed by the user", or "services should start sequentially in a static order", or "I'm going to ignore this until there are two implementations and a standard chiseled into a block of solid diamond" is absurd; you should try saying it to yourself in front of a mirror and keep a straight face. .. Change is pain, and you really have just two choices; impede the process and contribute nothing, or align yourself with it and help these folks improve the world a little. This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by Kevin Van Vechten 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com - Kevin On May 22, 2006, at 6:15 PM, André-John Mas wrote: Andre On 22-May-06, at 18:00 , Michael Bartosh wrote: On May 22, 2006, at 10:40 PM, Kevin Van Vechten wrote: not When the latter is far more accurate. _______________________________________________ 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… Andre, I think you're right on the mark, conceptually... however I think it's really more sample code that's necessary, not a GUI utility. (There's already a GUI utility you might want to check out <http://lingon.sourceforge.net/>). Sample code that can perform the tasks in question, such as "wait until the network interfaces seem to be up" and "wait until the disks seem to have mounted," would probably go a long way toward facilitating the adoption of launchd. (It's really not that much code to accomplish these tasks). Michael's correct that sysadmins should not need to worry about this. I think the burden is on Apple to provide the necessary information, and on developers (commercial or open source) to adopt the technology. Will it happen overnight? Certainly not. You can see that not even all of Apple's StartupItems were converted to launchd plists for Tiger. But launchd is the direction things are moving, and I think the benefits will become more apparent as we draw nearer the destination. Also, for what it's worth, there's a WWDC 2006 session scheduled: "Daemon Wrangling with Launchd." Probably a suitable compromise would be come up with GUI based utility that facilitates the creation of launchd based services. I am not sure what sort of form it would take on, but sometimes the best alternative is provide a suitable tool that facilitates the use of the technology at hand. I'd be surprised if there is not a platform specific line of code in your program. You can wrap your launchd support in #ifdef __LAUNCHD__ or something equivalent. It's overstating the problem to say that you can't have a unified code base. Adding Launchd support is a relatively small amount of code, I know from experience. I think your sysadmins (customers) will ultimately be pleasantly surprised by this investment. Your server can be automatically kept alive. This and other servers can be uniformly launched, stopped, and queried via launchctl or programmatically. That's fine. But what about the poor, dumb sysadmin who -can't write code-. These guys are not developers. Most sysadmins aren't. They take code developed by other people and deploy it themselves. And they need consistent ordering and dependencies that they can impose on that code. You (Kevin) seem to acknowledge this when someone brings it up. But the messaging from Apple seems to be 'use launchd, it's the wave of the future!' 'You might want to use launchd eventually, it has some cool features, but will create headaches for you in the short run'. You're right. Launchd is cool. It does some very cool things. 90% of the time those things are not accessible without dependency checking various systems require. I mean, at least add something to launchd.plist that can talk to configd.. wait for specific configd states, like configd's kicker does. That alone would make launchd -a lot- more useful. -mb This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by André-John Mas 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Andre On 22-May-06, at 18:00 , Michael Bartosh wrote: On May 22, 2006, at 10:40 PM, Kevin Van Vechten wrote: not When the latter is far more accurate. -mb _______________________________________________ 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/ajmas%40sympatico.ca _______________________________________________ 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… Probably a suitable compromise would be come up with GUI based utility that facilitates the creation of launchd based services. I am not sure what sort of form it would take on, but sometimes the best alternative is provide a suitable tool that facilitates the use of the technology at hand. I'd be surprised if there is not a platform specific line of code in your program. You can wrap your launchd support in #ifdef __LAUNCHD__ or something equivalent. It's overstating the problem to say that you can't have a unified code base. Adding Launchd support is a relatively small amount of code, I know from experience. I think your sysadmins (customers) will ultimately be pleasantly surprised by this investment. Your server can be automatically kept alive. This and other servers can be uniformly launched, stopped, and queried via launchctl or programmatically. That's fine. But what about the poor, dumb sysadmin who -can't write code-. These guys are not developers. Most sysadmins aren't. They take code developed by other people and deploy it themselves. And they need consistent ordering and dependencies that they can impose on that code. You (Kevin) seem to acknowledge this when someone brings it up. But the messaging from Apple seems to be 'use launchd, it's the wave of the future!' 'You might want to use launchd eventually, it has some cool features, but will create headaches for you in the short run'. You're right. Launchd is cool. It does some very cool things. 90% of the time those things are not accessible without dependency checking various systems require. I mean, at least add something to launchd.plist that can talk to configd.. wait for specific configd states, like configd's kicker does. That alone would make launchd -a lot- more useful. This email sent to ajmas(a)sympatico.ca This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by John Siracusa 23 May '06

23 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Thread-index: AcZ9/nS3s443dunxEdqmXQAKlbpFBg== Thread-topic: StartupItems User-agent: Microsoft-Entourage/11.2.3.060209 On 5/22/06, Peter Seebach <seebs(a)plethora.net> wrote: > My objection here is not to the basic idea of the launchd model for many > things; I think it is hands down the best way I've seen to handle inetd/cron > jobs or their equivalents. I just think it's doing an awful job of replacing > rc.d/startupitems. It's good for on-demand launches; it's not doing nearly > as good a job of startup. [...] > > Philosophically, it's wrong about startup. It CREATES the need for daemons > to do their own dependency checking, and requires everyone to duplicate > all the code to handle this, add new mechanisms, and so on. It INCREASES > code duplication. Try looking at it from another perspective: it moves knowledge out of your brain and into the code. Sure, maybe you know from experience (or from R-ing TFM) exactly when each item has to start with respect to all the others on your system(s) in your environment(s), but that's among the most fragile systems possible. "Have someone who knows what they're doing set it up." Or, "Copy this setup created at some point in the past by someone who knew what they were doing." IME, this leads to the "cutting the ends off the roast"[1] phenomenon in the long run--if you're lucky! If you're unlucky, the "smart" person wasn't actually that smart or just plain made a mistake (or three). Either way, the point is that the knowledge about when and how things should start is stored in a person--among the most unreliable of storage mediums :) Yes, you have the working system as an end-product, but little can be extrapolated from it. The only knowledge stored in the system is that "these services seem to work when launched in this order and in this particular environment." When it comes time to add a new service, you need that person again. And, of course, each system or project or business or whatever needs its own smart person. The launchd philosophy, OTOH, is to take all that knowledge and put it in the programs themselves. Then they just get thrown into the stew and launchd sorts them out. Need to add another service? If it's "launchd-ready" then you just add it to the pot. This process of changing code to work well with launchd seems "decentralized" from the perspective of an experience Unix admin and coder. But looking at the entire ecosystem, it's actually a centralizing force, extracting knowledge from experienced people and condensing it into code form, making it usable by a much wider audience. Even better, since all of the experienced people now have one place to focus their knowledge--the code itself rather than each of their own individual systems and rc files and what have you--the quality and robustness of that code will be very good. "Many eyes" and all that jazz. Then this work is then available to "the masses." That's the long view, as I see it. Unix has always been way too conservative in areas like this. Change means risk, but no change means that nothing will ever get much better. To really improve over the long term, practices like the careful placement of lines of text in specially named or numbered files and directories (in one of several different ways, depending on vendor and distant OS origins in the 1970s) simply have to give way to more robust systems usable with less risk by people with less knowledge and experience.[2] Robust, that is, from the perspective of "the world," not from the perspective of the fleshy life-form that spent 20 years leaning exactly where and how to put the ~100 services he's familiar with in the ~10 different OSes he's familiar with, and who will take that knowledge to his grave. Put it in the code; it'll live longer and do more good :) -John [1] http://www.snopes.com/weddings/newlywed/secret.asp [2] "Dumbing-down" you say? Do you know the hex values of all the instructions supported by your CPU? "Progress," I say. _______________________________________________ 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: StartupItems
by Michael Bartosh 22 May '06

22 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On May 22, 2006, at 10:40 PM, Kevin Van Vechten wrote: not When the latter is far more accurate. -mb _______________________________________________ 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… I'd be surprised if there is not a platform specific line of code in your program. You can wrap your launchd support in #ifdef __LAUNCHD__ or something equivalent. It's overstating the problem to say that you can't have a unified code base. Adding Launchd support is a relatively small amount of code, I know from experience. I think your sysadmins (customers) will ultimately be pleasantly surprised by this investment. Your server can be automatically kept alive. This and other servers can be uniformly launched, stopped, and queried via launchctl or programmatically. That's fine. But what about the poor, dumb sysadmin who -can't write code-. These guys are not developers. Most sysadmins aren't. They take code developed by other people and deploy it themselves. And they need consistent ordering and dependencies that they can impose on that code. You (Kevin) seem to acknowledge this when someone brings it up. But the messaging from Apple seems to be 'use launchd, it's the wave of the future!' 'You might want to use launchd eventually, it has some cool features, but will create headaches for you in the short run'. You're right. Launchd is cool. It does some very cool things. 90% of the time those things are not accessible without dependency checking various systems require. I mean, at least add something to launchd.plist that can talk to configd.. wait for specific configd states, like configd's kicker does. That alone would make launchd -a lot- more useful. This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by seebs＠plethora.net 22 May '06

22 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com In message <5E024134-07E3-46B7-870D-268CB3D7ABB3(a)opendarwin.org>, Kevin Van Vec hten writes: >I'm not advocating polling models, there are callback models that >suffice. Fair enough, but even MORE system-specific. >In the short term I agree with you. You have some more work to do, >but in the long term, this approach is sustainable and hopefully will >not require further churn. It may or may not. I just don't find myself convinced that every daemon in the world should acquire all this extra sanity-checking. I like to isolate repetitive tasks; I would rather see ONE program to dependency checking than DOZENS. >> Since when? Since 1980? Since 1990? >Since Mac OS X 10.0. I can't/won't speak for earlier systems. Imagine that I'm a UNIX guy with a half-dozen machines already running. Why should I care about OS X? It's imposing a totally new model on my code that contradicts how my code has worked fine on every other system for twenty years. >I'd be surprised if there is not a platform specific line of code in >your program. There may be some, but there's damn little. I write portable, standard, code. >You can wrap your launchd support in #ifdef >__LAUNCHD__ or something equivalent. It's overstating the problem to >say that you can't have a unified code base. Adding Launchd support >is a relatively small amount of code, I know from experience. I >think your sysadmins (customers) will ultimately be pleasantly >surprised by this investment. Your server can be automatically kept >alive. This and other servers can be uniformly launched, stopped, >and queried via launchctl or programmatically. Hmm. Tell you what: When there's a published standard that is not Apple-specific, and a second independent implementation I can compare with, I'll think about it. Right now, I have Apple totally overhauling the way daemons are started. I have no reason to believe that this one will survive. >It's clear you're dissatisfied with having to change from what you're >used to, and I appreciate that. I don't think any further amount of >discussion is going to change that. However, I think you'd be >pleasantly surprised if you gave the launchd model a chance. I think it has some potential. But ultimately, the more I think about it, the more I think it's just plain wrong. Dependency checking is not something that should be duplicated in every program. >I think your concerns are completely legitimate, but we're faced with >a difference in opinion as to how they're most effectively addressed >(i.e. are they a startup problem or a process problem?) I suspect >the best solution is for more documentation and sample code to be >written about launchd, to illustrate how to achieve these goals >within your process. Yes. Well, as a recent example, I have an existing fire-and-forget program. I don't want to modify it. How should I do a launchd.plist file to start it? The obvious idea is to use RunAtLoad. If you do this, launchd hangs forever. Why? Because despite every last piece of documentation saying that you must NEVER fork and detach, and you MUST NOT close file descriptors, if you don't fork-and-detach and close file descriptors in a RunAtLoad process, launchd waits for it to terminate before doing anything else. I could, I suppose, rewrite my program to add launchd checking and so on to what is essentially a ten line shell script with a while loop. I'm not sure how I'd go about doing this, because my kornshell documentation makes no mention of a fully functional IPC system. My objection here is not to the basic idea of the launchd model for many things; I think it is hands down the best way I've seen to handle inetd/cron jobs or their equivalents. I just think it's doing an awful job of replacing rc.d/startupitems. It's good for on-demand launches; it's not doing nearly as good a job of startup. Philosophically, it's right about inetd/cron. It eliminates the need for daemons to do their own setup work and have everyone duplicate the various attempts to drop privileges as soon as possible but not to soon, and so on. It REDUCES code duplication. Philosophically, it's wrong about startup. It CREATES the need for daemons to do their own dependency checking, and requires everyone to duplicate all the code to handle this, add new mechanisms, and so on. It INCREASES code duplication. -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: StartupItems
by Kevin Van Vechten 22 May '06

22 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On May 22, 2006, at 1:25 PM, Peter Seebach wrote: Historically it might have been safe to assume disk availability after "startup," but the whole point is that such assumptions are fragile at best, and therefore shouldn't be made. Disks (especially FireWire and USB) can come and go long after "startup," so it really isn't "the job of the startup system" to ensure that they're there. It's the job of the process. Correct. The StartupItem dependencies were not a panacea. In fact, a lot of third party applications had trouble with the dependency model as technologies moved from one startup item to the next (even before the shift to launchd). Maintaining dependency information in an abstract parallel universe is always prone to mistakes. The advantage of processes implicitly declaring dependencies (via blocking IPC etc.) or explicitly declaring them (via callbacks for system state changes) is inherently more robust. Should I? Since Mac OS X 10.0. I can't/won't speak for earlier systems. configd is responsible for bringing up the network interfaces. Originally launched by a startup item, it was subsequently moved to a mach_init plist in Jaguar. The point is that there was never an explicit dependency here. If you want to replicate the historic behavior, then put a sleep(60) in your main() function and hope for the best, because this is essentially all that was ever happening anyway. I'm not talking about "only on a Mac". Interfaces can come and go dynamically even on Mac OS X Server, so I don't really buy the argument that detecting this fact isn't necessary on server systems. - Kevin _______________________________________________ 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… In message <8F3679B6-2203-46A8-9D7C-A2CEA8D1BFB3(a)opendarwin.org>, Kevin Van Vec hten writes: I think it's the job of the sysadmin. Having every process constantly check for disk availability doesn't help all that much; it's load- creating, and it doesn't solve the problem. I'm not advocating polling models, there are callback models that suffice. There comes a time when the UNIX philosophy should win; 10% of the coding does 90% of the job. Dealing with disk changes is probably a human task. It is, but inventing yet another new way of doing it doesn't help me much. :) In the short term I agree with you. You have some more work to do, but in the long term, this approach is sustainable and hopefully will not require further churn. Actually you should have always tested for this in your code. Since when? Since 1980? Since 1990? I'm talking general UNIX. I don't have any interest in crippling my code to a single platform. The historical practice has been to figure out how your system provides ordering, and use that to launch code at the right time. On SysV, you link your init script to SXXdaemon, where XX is larger than the number for the network init script. In NetBSD/FreeBSD, you put "REQUIRE: network" in your rc.d script. When I say "server systems", I don't mean "systems running OS X server". I'm talking about general practices for people running a server. I've yet to see a real webserver want to use a dynamically up/down interface. And the "new requirements" that lauchd "imposes" on your processes generally have been there all along, and it's just been a matter of luck that things worked without taking the time to address these issues. No. Outside of the Mac, everyone's provided a nice luck-free way to ensure that items get launched at the right time. It might be as dumb as the very old "put it in /etc/rc after the things it depends on", but the ordering control has always been there. Launchd is expecting me to modify the code of my server application to solve an administrative task, and to do so in a completely Mac-specific way. No one else has done that. I can take a daemon written in 1990 and run it without modifying the code on any other system, by using their script or config file interface for specifying what its requirements are. On the Mac, I'm being told it's suddenly up to me to modify my application code. I'm not sure this is wrong; I think UNIX could benefit a lot from additional dependency handling in applications. However, it's a major change in philosophy, and the short-term effect is that, if I have to support more than one UNIX platform, the Mac is gonna be my absolute last choice, because it's the one that requires me to encode system-specific configuration knowledge into my code, rather than having that be in the part of the system that handles startup. I can no longer have a single unified source tree if I want to target the Mac. I'd be surprised if there is not a platform specific line of code in your program. You can wrap your launchd support in #ifdef __LAUNCHD__ or something equivalent. It's overstating the problem to say that you can't have a unified code base. Adding Launchd support is a relatively small amount of code, I know from experience. I think your sysadmins (customers) will ultimately be pleasantly surprised by this investment. Your server can be automatically kept alive. This and other servers can be uniformly launched, stopped, and queried via launchctl or programmatically. It's clear you're dissatisfied with having to change from what you're used to, and I appreciate that. I don't think any further amount of discussion is going to change that. However, I think you'd be pleasantly surprised if you gave the launchd model a chance. I think your concerns are completely legitimate, but we're faced with a difference in opinion as to how they're most effectively addressed (i.e. are they a startup problem or a process problem?) I suspect the best solution is for more documentation and sample code to be written about launchd, to illustrate how to achieve these goals within your process. This email sent to site_archiver(a)lists.apple.com

1 0

Re: StartupItems
by seebs＠plethora.net 22 May '06

22 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com In message <8F3679B6-2203-46A8-9D7C-A2CEA8D1BFB3(a)opendarwin.org>, Kevin Van Vec hten writes: >Historically it might have been safe to assume disk availability >after "startup," but the whole point is that such assumptions are >fragile at best, and therefore shouldn't be made. Disks (especially >FireWire and USB) can come and go long after "startup," so it really >isn't "the job of the startup system" to ensure that they're there. >It's the job of the process. I think it's the job of the sysadmin. Having every process constantly check for disk availability doesn't help all that much; it's load-creating, and it doesn't solve the problem. There comes a time when the UNIX philosophy should win; 10% of the coding does 90% of the job. Dealing with disk changes is probably a human task. >Correct. The StartupItem dependencies were not a panacea. In fact, >a lot of third party applications had trouble with the dependency >model as technologies moved from one startup item to the next (even >before the shift to launchd). Maintaining dependency information in >an abstract parallel universe is always prone to mistakes. The >advantage of processes implicitly declaring dependencies (via >blocking IPC etc.) or explicitly declaring them (via callbacks for >system state changes) is inherently more robust. It is, but inventing yet another new way of doing it doesn't help me much. :) >Actually you should have always tested for this in your code. Should I? Since when? Since 1980? Since 1990? >configd is responsible for bringing up the network interfaces. >Originally launched by a startup item, it was subsequently moved to a >mach_init plist in Jaguar. The point is that there was never an >explicit dependency here. If you want to replicate the historic >behavior, then put a sleep(60) in your main() function and hope for >the best, because this is essentially all that was ever happening >anyway. I'm not talking about "only on a Mac". I'm talking general UNIX. I don't have any interest in crippling my code to a single platform. The historical practice has been to figure out how your system provides ordering, and use that to launch code at the right time. On SysV, you link your init script to SXXdaemon, where XX is larger than the number for the network init script. In NetBSD/FreeBSD, you put "REQUIRE: network" in your rc.d script. >Interfaces can come and go dynamically even on Mac OS X Server, so I >don't really buy the argument that detecting this fact isn't >necessary on server systems. When I say "server systems", I don't mean "systems running OS X server". I'm talking about general practices for people running a server. I've yet to see a real webserver want to use a dynamically up/down interface. >And the "new requirements" that lauchd "imposes" on your processes >generally have been there all along, and it's just been a matter of >luck that things worked without taking the time to address these issues. No. Outside of the Mac, everyone's provided a nice luck-free way to ensure that items get launched at the right time. It might be as dumb as the very old "put it in /etc/rc after the things it depends on", but the ordering control has always been there. Launchd is expecting me to modify the code of my server application to solve an administrative task, and to do so in a completely Mac-specific way. No one else has done that. I can take a daemon written in 1990 and run it without modifying the code on any other system, by using their script or config file interface for specifying what its requirements are. On the Mac, I'm being told it's suddenly up to me to modify my application code. I'm not sure this is wrong; I think UNIX could benefit a lot from additional dependency handling in applications. However, it's a major change in philosophy, and the short-term effect is that, if I have to support more than one UNIX platform, the Mac is gonna be my absolute last choice, because it's the one that requires me to encode system-specific configuration knowledge into my code, rather than having that be in the part of the system that handles startup. I can no longer have a single unified source tree if I want to target the Mac. -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: StartupItems
by Kevin Van Vechten 22 May '06

22 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On May 22, 2006, at 11:19 AM, Peter Seebach wrote: - Kevin _______________________________________________ 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… What's the launchd way for my existing program which runs on 30 other UNIX platforms to request that it be launched only when a configuration file it needs is accessible? On other systems, I'd put it in startup after all the disk-mounting. What do I do in the launchd model? My program doesn't have any hooks for querying disk availability, *BECAUSE THAT IS THE JOB OF THE STARTUP SYSTEM*. Or at least, always has been. Historically it might have been safe to assume disk availability after "startup," but the whole point is that such assumptions are fragile at best, and therefore shouldn't be made. Disks (especially FireWire and USB) can come and go long after "startup," so it really isn't "the job of the startup system" to ensure that they're there. It's the job of the process. The complications of dependency checking have not been removed; they've been moved from specifications in the plist file (or rc file, or whatever) into extra code in my application. Correct. The StartupItem dependencies were not a panacea. In fact, a lot of third party applications had trouble with the dependency model as technologies moved from one startup item to the next (even before the shift to launchd). Maintaining dependency information in an abstract parallel universe is always prone to mistakes. The advantage of processes implicitly declaring dependencies (via blocking IPC etc.) or explicitly declaring them (via callbacks for system state changes) is inherently more robust. What's the launchd way for my existing program, which scans for running network interfaces and binds to them, to ensure that it's run only after the network is up? I don't care about laptop issues, I'm writing a server app. I don't want to have to add special code to my app to scan repeatedly because ONE SYSTEM won't let me just schedule my item "after the network is up". Actually you should have always tested for this in your code. configd is responsible for bringing up the network interfaces. Originally launched by a startup item, it was subsequently moved to a mach_init plist in Jaguar. The point is that there was never an explicit dependency here. If you want to replicate the historic behavior, then put a sleep(60) in your main() function and hope for the best, because this is essentially all that was ever happening anyway. Interfaces can come and go dynamically even on Mac OS X Server, so I don't really buy the argument that detecting this fact isn't necessary on server systems. Launchd has a lot to offer, especially for server processes, like process keep-alive. And the "new requirements" that lauchd "imposes" on your processes generally have been there all along, and it's just been a matter of luck that things worked without taking the time to address these issues. This email sent to site_archiver(a)lists.apple.com

1 0

Re: compile for i86 on my PPC?
by Paul Archibald 22 May '06

22 May '06

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