Replace inetd/xinetd with "upstart" events

In my opinion process 1 shouldn't handle internet connections. If there was a security flaw, a {cr,h}acker could bring down a system easily - Alex

Good point; however, on all systems I know of, inetd/xinetd runs as root and so has the same potential to disrupt the system. Not an argument for, but, it does undermine somewhat your argument against. -- Gerald Butler

Here are some thoughts for inetd services using upstart (I have next to no experience of upstart or inetd, but words are cheap):
A new process (e.g. upstart-net) could replace inetd. It would need the ability to listen on low ports, but could be otherwise unprivileged. Some new event configuration language would be required, possibly something like "inetd on tcp-21" which would work just like "start on tcp-21", except that the service would be fed the relevant inetd-style stdin. It seems like this could even be generalised to allow any process to have some stdin from its initiator.
Another idea is having "start on tcp-21" (but not "inetd on tcp-21") unbind upstart-net from port 21 first, potentially allowing on-demand standalone servers. -- Chris Amin

Im not even on the Upstart team but one point occured to me. The main upstart binary is called "init" as so it works with software expecting the init binary. If this was to be done, an "inetd" binary would have to be created. I also think that this should not be in the main upstart binary as it causes bloat. Just my $0.02 -- Philip (lsproc)

I also think that init (upstart) should NOT play the role of idetd/xinetd. However, there is one way - the existing (or new) inetd/xinet daemon could be extended/modified is such a way, that after all the security checks it will ask upstart to start (or stop if connection closed) the service required. This communicaion could be easily done through dbus or libupstart. I think that it uses the best from both worlds - every program does what it can do best, inetd watches network connetions and checks all the security issues, upstart starts/stops and takes care about the processes. Dan.

I'm with DAN on this one Inetd should be modified to use upstart to start/stop jobs. This will leave inetd doing what it does best guarding and monitoring network ports and handing over port messages after the appropriate process has started. While leaving upstart to do what it was intended for controlling and monitoring processes. You might not even have to change the inetd code it's self since some config file somewhere probably defines how to start the service. For example if the /etc/services file defines ftp on port 22 something must define how to start the ftp daemon, we would only have to change that definition to use upstarts initctl to start ftp. This definition seams to be in inetd.conf. BTW wikipedia seams to think upstart is already replacing inetd . RmsMit

How about just spawning tcpsvd (http://smarden.org/ipsvd/tcpsvd.8.html) with the right arguments? Can be done right now and works well. -- Tv

^^^ That could be the way to implement it. Tvs way but not every script with 'exec tcpsvd ...' but something simple like 'listen on ...' and the same options as tcpsvd. Behind the scenes, upstart would do what tcpsvd is doing. I have expanded the draft somewhat with some arguments and design ideas. -- Daniël Sonck