Differences between revisions 9 and 10
Revision 9 as of 2011-05-28 15:22:12
Size: 5857
Editor: daniel-sonck
Revision 10 as of 2011-08-26 04:10:19
Size: 5859
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Launchpad entry''': [https://launchpad.net/products/upstart/+spec/replace-inetd https://launchpad.net/products/upstart/+spec/replace-inetd]  * '''Launchpad entry''': [[https://launchpad.net/products/upstart/+spec/replace-inetd|https://launchpad.net/products/upstart/+spec/replace-inetd]]

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).

  • Why do we want to do this?
    • To create a consistent system for starting services and jobs whether they are network services or ordinary services.
  • What advantage would 'upstart' have over 'inetd/xinetd'?
    • It could directly handle events.
    • You could start listening on port 80 ONLY when the httpd service needs to be run. This would free port 80 when init won't start httpd
    • You could start multiple services on a given port because some services won't be run (wrong events/not started)
  • 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?
    • It might make the internal structure complex, but it would create a consistent way of defining services, whether an init or an inetd service (or cron/anacron.
  • Doesn't inetd/xinetd peform a lot of security checks and such before starting the services? Is this appropriate functionality for 'upstart'?
    • The extra security checks could improve inits overall security.
  • 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.
    • inetd starts services when there is a connection, it doesn't act on data received from the connection. The only risk is that a wrong service (which can also be started by inetd) is started and does harm. The main risks depend on the scripts and services used.

  • What would be some advantages of 'upstart' handling incoming network connections as opposed to 'inetd/xinetd'?
    • One daemon less
    • Only listen on ports when they will be used
    • No extra file for defining inetd/xinetd processes

Use cases

  • 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...)
  • A server could use a very simple http daemon as a backup when their main daemon is down. Listen on ports which are actually going to be used.
    •      inet-service
           listen on http
           start on stopped apache
           stop on starting apache
           exec /usr/bin/httpd -c <some-configuration>


This scope of this specification is limited to ...


  • There would be a new inet-service tag to the script to notify init that it is an inetd script.

  • An listen on tag with e.g. 22/tcp, 80/udp or ftp to specify which port(s) init would listen.

  • A possibility is to use or to use only one port and and to use all ports.

    •      inet-service
           listen on 80/tcp and 8080/tcp
           exec /usr/bin/httpd

      Would start httpd when there is a connection on port 80 and it would start httpd when there is a connection on port 8080.

           listen on 80/tcp or 8080/tcp
           exec /usr/bin/httpd

      Would start httpd when there is a connection on port 80 or port 8080. If one port is connected, the other port won't be used until the used port is freed.
      This allows the server to be started only once and on the port that is first used.

  • There could be a way to use instances by defining new environment variables CONNECTED_HOST, CONNECTED_PORT



Data preservation and migration

Unresolved issues

ReplaceInetd (last edited 2011-08-26 04:10:19 by localhost)