site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com #!/bin/sh while [ ! -d /Volumes/NAS ] do sleep 1 done exec /usr/sbin/my_favorite_daemon davez On May 11, 2007, at 2:14 PM, Peter Seebach wrote: Example usage: /usr/local/bin/depends -p 80 run_me_after_apapche /usr/local/bin/depends -d /Volumes/NAS run_me_after_network_mounts Obviously, this program could then be used in launchd jobs. (It would probably want options to distinguish between "wait forever" and "error out if the dependency isn't met") Are there obvious problems that real launchd-based systems face, which cannot be addressed reasonably well by the use of such a program? -s _______________________________________________ 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/zarzycki%40apple.com _______________________________________________ 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... We've actually discussed this a few times within Apple. We all agree that it would be a great idea to provide system administrators this kind of crutch so they can workaround software bugs or design flaws. Unfortunately, we all have higher priorities for the foreseeable future. For whatever it may be worth, you can already fake a lot of this stuff up with a shell script right now. The problem is knowing what tools to run and how. For example: I'm sure a semi-smart person could probably use the same trick outlined above with the 'nc' tool to check for port/host reach-ability. So, as we all know, for reasonably sound reasons, launchd does not have any support for dependency checking. And, as many of us know, there are some programs out there that must be run, cannot run without certain dependencies, and cannot be modified. (Whether that's "cannot" as in company policy, or "cannot" as in "we only have binaries" doesn't matter much.) Imagine, if you will, a program that does exactly one thing: Check for one or more requirements, and launch a specified program when they are met. No attempt is made to solve the abstract/general problem of deadlock; rather, this program leaves it to the admin to figure out what the deadlock risks are. This email sent to zarzycki@apple.com This email sent to site_archiver@lists.apple.com