Busybox httpd sends output of stderr to the Website

[Laurent Bercot]

>Unless they do want _remote user_ to see the message.
>
>For example, if you start a shell over a tcp connection
>("poor man's telnet"), you do want to see shell error messages
>when you work in that shell, right?
>
>IOW: inetd can't know which behavior is desirable, since both make 
>sense.
>
>So the best thing is to follow the existing established practice
>(if it exists). I googled for it and there is a somewhat weak 
>indication
>that inetd's of various Unixes did send stderr to the socket.
>Even wikipedia says:
>"...
>inetd hooks the sockets directly to stdin, stdout and stderr
>of the spawned process"

  Ah, wikipedia, that famous normative specification site. ;)

  Note that if stderr is not automatically redirected to the client,
it is easy for a service to do so if it wishes: run
"sh -c 'exec foobard 2>&1'" instead of "foobard".
  And if the service does not want stderr redirected, then it has nothing
to do - the infrastructure running the service is in charge of sending
stderr to an appropriate logging place. This is the behaviour of 
tcpserver
with a supervision suite such as s6 or runit, where the supervision tree
also manages a logging chain and services can do what they want with
their stderr - redirect it to the client, get their own logger, or just
let the supervision tree handle it (i.e. send it to the default system
logger).

  Whereas if stderr is automatically redirected to the client by the
superserver (which is the case with bb's inetd), then everything's fine
as long as all services want that behaviour, but if a service does *not*
want its stderr redirected, what should it do? There is no "let the
infrastructure handle it" option. The service has to choose a place for
its stderr to go, and the choices are bleak: /dev/null, a log file
(which can grow uncontrollably), or a fifo to a previously defined
logging program that cannot take advantage of the superserver model and
that the inetd service is silently relying on. That's more brittle, and
more work for the administrator.

  I really recommend not using inetd and spawning a tcpserver process
instead for every inetd-mode service you have. It is much more 
comfortable
to admin in the long run.

--
  Laurent