On Thu, Mar 23, 2017 at 11:45 AM, Steve Bennett <ste...@workware.net.au> wrote: > >> On 23 Mar 2017, at 5:51 PM, Dirk Lohse <d.lo...@meier-nt.de> wrote: >> >> A workaround for me is to not use inetd mode. But the reason for this >> behavior should be found and fixed - I think. >> >> Dirk >> > > See networking/inetd.c: > > /* manpages of inetd I managed to find either say > * that stderr is also redirected to the network, > * or do not talk about redirection at all (!) */ > if (!sep->se_wait) /* only for usual "tcp nowait" */ > xdup2(STDIN_FILENO, STDERR_FILENO); > > inetd is tying stdout and stderr together. > > Personally I think this is wrong since it generally means that > inetd services must be careful never to write to stderr.
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" _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox