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
