Subject: where should stand-alone daemon binaries really live?
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 08/07/2000 13:55:46
[[ I think in the larger scope of things this is more of a
tech-userlevel issue, not tech-net.... ]]
[ On Monday, August 7, 2000 at 09:27:03 (-0700), Jason R Thorpe wrote: ]
> Subject: Re: CVS commit: basesrc
> On Mon, Aug 07, 2000 at 06:21:03PM +0200, Johan Danielsson wrote:
> > > For instance, telnetd expects an open socket on stdin, not a
> > > terminal session
> > telnetd -debug?
> That is hardly the normal use of telnetd.
One could equally argue that's true for all the /usr/sbin/*d's, even, or
especially, inedtd iteslf.....
Now that "/etc/rc.d/* start" works it hardly seems like a good idea to
continue to "encourage" the manual starting of daemons by leaving them
/usr/sbin (even /sbin/routed, for what it's worth, should probably not
normally be started directly from their binary by hand).
The technical reason for this is that at least some of these daemons
often, or even normally, have command-line parameters without which they
will not function as required for a normally running production system
(such as '-l' for inetd itself).
However just as with 'telnetd -debug' the admin is still free to
manually start any given daemon with any (or no) parameters provided
that they explicitly specify the full pathname.
Of course there are lots of arguments against moving these programs, not
the least of which is the upgrade headache this would cause everyone.
There's also the possibility the non-touch-typists might argue that
"/etc/rc.d/inetd start" is too much to type vs. "inetd -l".
In the end all I'm really saying is that I think it's extremely
arbitrary to argue that just because a daemon normally runs only from
inetd that it should live in /usr/libexec. After all there's really
only a tiny amount of programming between the current single instance
daemons and making them all capable of standing alone. While it's true
that running the current single-instance daemons by hand in any useful
way is often "hard", I don't think that has any real meaning in this
issue since it can most definitely be done.
In fact *I* would rather that all daemons stood alone and be run from
something that can monitor them and restart them should they fail, such
as init or something very much like it. If the essential bits of inetd
(the listen loop, rate limiters, logging, etc.) were in a library (just
as daemon() and libwrap are now), getting all this code "right" for
every instance would still be a shared problem and I think the chance
for better reliability would offset the relatively minor amount of
additional runtime system resources that would be required (a few more
process slots, a wee bit more heap space, etc.).
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>