site_archiver@lists.apple.com Delivered-To: Darwin-dev@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@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... In message <8F3679B6-2203-46A8-9D7C-A2CEA8D1BFB3@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@lists.apple.com