Subject: Re: where should stand-alone daemon binaries really live?
To: NetBSD Userlevel Technical Discussion List <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 08/07/2000 11:17:02
On Mon, 7 Aug 2000, Greg A. Woods wrote:
# Date: Mon, 7 Aug 2000 13:55:46 -0400 (EDT)
# From: Greg A. Woods <email@example.com>
# Reply-To: NetBSD Userlevel Technical Discussion List
# To: NetBSD Userlevel Technical Discussion List <firstname.lastname@example.org>
# Cc: email@example.com
# Subject: where should stand-alone daemon binaries really live?
# [[ 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.....
That's a straw man.
# 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).
Probably not normally. I've had reason to do so, the /etc/rc.d/* start
Please don't look to cripple the sysadmins who do know what they are
# 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).
inetd does not require -l to run.
# 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.
Sigh. Looks like I get to add /usr/libexec to my $PATH. I was hoping
to avoid that.
# 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.
I think you're looking at the picture from a different angle than
most of us see it. Well, I, at least (sorry if I misspeak for most
of you :-) see it quite differently and less arbitrary than you do.
It's not just "running from inetd" but "normally reserved for being
started by another program in general", whether it is inetd or anything
else that might want to do that. The programs in /usr/libexec are
also more or less one-off daemons that aren't going to stick around
once their function is finished -- getty exits (or execs its way out)
once its function is finished and then is restarted to wait for another
connection, for example. The rest are started on demand, rather than
being always active.
Looking at it from an admin point of view, it actually declutters /usr/sbin
by quite a bit, something which I find rather attractive.
# 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.
But we don't NEED them to be standing alone. Usually. The times we
do need them, we can make it happen from the command line. Pretty
# 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.
Greg, I will note again as has been noted before that if *you* were
designing all of this it would look and run surprisingly similarly
to the reasons that Berkeley was designed as it was in the first place.
# 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.).
All you pundits who are advocating this change are missing the point:
"It isn't broken. Don't fix it."
BSD: the free unix for the rest of us.