<p dir="ltr"><br>
On Jun 19, 2015 9:16 PM, "Rafał Miłecki" <<a href="mailto:zajec5@gmail.com">zajec5@gmail.com</a>> wrote:<br>
><br>
> On 19 June 2015 at 14:44, Yousong Zhou <<a href="mailto:yszhou4tech@gmail.com">yszhou4tech@gmail.com</a>> wrote:<br>
> > On 19 June 2015 at 19:34, Rafał Miłecki <<a href="mailto:zajec5@gmail.com">zajec5@gmail.com</a>> wrote:<br>
> >> Using pipe automatically switches service to block buffering which kind<br>
> >> of breaks our logging. We won't get anything from FD until the buffer<br>
> >> gets filled fully or the service exits. This makes log messages appear<br>
> >> with an unwanted delay.<br>
> >> Switching to PTY fixes this issue. Service prints to the "standard"<br>
> >> stdout (no piping) but the messages go (line buffered) to the master FD<br>
> >> anyway.<br>
> >> It was successfully tested with all 4 variants of "stdout" and "stderr"<br>
> >> ubus arguments.<br>
> >><br>
> ><br>
> > I do not like this because<br>
> ><br>
> >  - Conventionally, services will drop their inherited controlling<br>
> > terminal for preparation of becoming a daemon.  Adding back that<br>
> > controlling terminal by login_tty() for alleviating possible delay<br>
> > when logging stdio sounds not right.<br>
><br>
> Do you have any other idea?<br>
> The delay isn't "possible", I think it occurs with 90%+ of apps. I'm<br>
> not aware of many apps (except for grep maybe) that calls "fflush"<br>
> after every printf. It simply makes reading real-time logs with<br>
> "logread" not working at all.<br>
><br>
><br>
> >  - I am biased... in that the ossherd [1] package depends on the fact<br>
> > processes started by procd do not have controlling terminals and this<br>
> > will unattended password login with ssh  :)<br>
><br>
> I'm afraid I don't understand this part. In any case, you don't have<br>
> to use logging in your init.d script. It's an option.<br>
></p>
<p dir="ltr">It's a hacky init script trying to start SOCKS5 proxies with openssh-client.  Password authentication has to be used in this case.</p>
<p dir="ltr">><br>
> > Anyway, the implementation is not complete.<br>
> ><br>
> >  - epipe[] is still there.<br>
><br>
> It is supposed to be. That's the only way to keep logging of stdout<br>
> and stderr separated. Read my comment (in the code) about epipe.<br>
><br>
><br>
> >  - aslave needs to be closed when login_pty() failed<br>
><br>
> I'll fix that.<br>
><br>
><br>
> >  - login_pty() and dup2() used together<br>
><br>
> That's correct, expected, on purpose.<br>
></p>
<p dir="ltr">but login_pty will do dup2 on all 3 fd's with aslave.  it's duplicate work and has side effects (regarding a pty stdin).</p>
<p dir="ltr">I think currently not many programs need procd_set_param stdout.  most of the time if not always stderr, apart from syslog, is used for logging and error reporting.  If that is agreed, then we can conclude that it is at least a relatively rare case that we need to log stdout of the program, and if that is the case we can afford and should patch the program itself to use line buffered io with stdout.</p>
<p dir="ltr">Regards</p>
<p dir="ltr">                    yousong</p>
<p dir="ltr">><br>
> >  - aslave should be closed in parent<br>
><br>
> Like closefd(aslave) which my patch does?</p>
<p dir="ltr">sorry, i missed that one before.<br>
</p>