Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
This long-term goal of "upstart" is to act as a replacement for _nearly_ all job control services (e.g. init, inetd, cron, anacron, at). This specification proposes how the inetd/xinetd replacement functionality will work.
This will permit jobs (aka services) to be run in response to incoming internet connections to various well-know ports (standard inetd /etc/services).
- NOTE: RATIONALE NEEDS SOME WORK! I'M HAVING DIFFICULTY JUSTIFYING THE NEED TO REPLACE 'inetd/xinetd' WITH 'upstart'.
- Why do we want to do this?
- What advantage would 'upstart' have over 'inetd/xinetd'?
- Is handling incoming network connections and starting the appropriate services the same thing as starting and stopping jobs in response to various system states?
- Doesn't this make 'upstart' overly complex?
- Doesn't inetd/xinetd peform a lot of security checks and such before starting the services? Is this appropriate functionality for 'upstart'?
- What are the security implications of moving exposed network services to an "init-like" service? If handled by upstart, this should probably be an seperate instance of it.
- What would be some advantages of 'upstart' handling incoming network connections as opposed to 'inetd/xinetd'?
- On Mac OS X, cupsd is normally run on-demand by launchd. The first connection on port 631 or the domain socket starts up cupsd, and then it takes over accepting connections for launchd. After a period of inactivity, cupsd can exit to return control of the sockets to launchd. The only time cupsd runs all the time is if you are sharing printers. (the same mechanism is used for Samba, Apache, etc. which speeds up booting...)
This scope of this specification is limited to ...
Data preservation and migration