• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: StartupItems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: StartupItems


  • Subject: Re: StartupItems
  • From: Andrew White <email@hidden>
  • Date: Thu, 01 Jun 2006 17:12:22 +1000


Peter Seebach wrote:

If you want a good startup system that deals well with dependency ordering
and such, get NetBSD's rc.d.  It works and it solves the problem, and it
doesn't step on launchd's area of expertise (on-demand launching) at all.

I've used rc.d on NetBSD to build a gateway that needed to cope with all sorts of interesting dynamic situations on the fly, including downlink interfaces appearing and disappearing and the uplink interface address changing. We actually ended up writing our own custom version of the rc architecture to handle the dynamic domain and allow us to restart appropriate portions of it.


The biggest problem was pushing various pieces of dynamic information (like the address of the uplink) into static configuration files and then restarting the appropriate services. Several key tools (including bind and dhcpd, as well as rc.d itself) weren't prepared for an environment where the server's IP addresses could be changed at will and the rest of the system was expected to cope.

Similar to others, we also had problems with the definition of "started". "Started" can mean anything from "the executable has been forked" to "the executable has acquired the necessary resources" to "we have meaningful data". In a dynamic system, you want the parallelism offered by being able to "start" everything and have the system reconfigure when "we have meaningful data", rather than need to build in artificial delays to make sure that things that have finished running their startup script have actually "started".


Summary: the rc architecture is designed to support a "start once" model, with any dynamic restarting being done manually and in a controlled manner by a sysadmin. As soon as you create an environment where it's allowed and even expected that the goalpost can move at any time and the system should chase them then the rc system quickly shows its flaws. Since you have to support this dynamic system anyway, why not make startup work the same way, rather than special-case it?


--
Andrew White

--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: StartupItems
      • From: email@hidden (Peter Seebach)
  • Next by Date: Re: Behavior of "less" on different systems?
  • Next by thread: Re: StartupItems
  • Index(es):
    • Date
    • Thread