>Yes, that seems desirable. It's the inetd-for-everything model that >Apple uses. The problem, I suspect, is that unlike telnetd, rpcbind has >a doors interface, and we don't have an inetd for doors. (I don't know >whether one is currently possible.)
The main issue with inetd is that it cannot spawn a service which listens on multiple ports like rpcbind does (similarly, rpc.cmsd and others are still broken and are still started only partially correctly because PSARC decided that my proposed way of fixing this, handing off a bunch of fds to an inetd child, "did not do" and so we are now still living with a broken fix for that stateful daemon. Inetd would need to open around 10-20 fds all listening to a separate instance of rpcbind/portmap and then hand them all of to rpcbind when it starts; there is no mechanism to do so. BTW, rpcbind does not use a doors interface. The RPC-over-doors daemons use fixed rendezvous points (/var/run/rpc_door/rpc_PROG.VERS) so no registration is needed; write permission to /var/run/rpc_door, however, is) Casper
