Adding more gnomes into the loop. ;-)
Am 15.01.2016 um 00:29 schrieb Hua Zhong:
> [resend as pain text mode]
>
> Hi,
>
> While working on Fedora 18, we found that sometimes telnetd would
> close connections unexpectedly:
>
> Trying 172.24.17.14...
> Connected to 172.24.17.14.
> Escape character is '^]'.
> Connection closed by foreign host.
>
> in.telnetd runs login as its subprocess and communicates with it
> through the pty master/slave descriptors. Initially reading the pty
> master might return EIO, until the slave is ready. But if it gets EIO
> after having read valid data, it breaks out.
>
> What I find is that in.telnetd would sometimes get something like this
> (25646 is login, and 25645 is telnetd) - getting EIO after reading
> something:
>
> 25646 ioctl(0, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS,
> {B9600 opost isig icanon echo ...}) = 0
> 25646 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B9600 opost isig icanon echo ...}) = 0
> 25646 close(0) = 0
> 25646 close(1) = 0
> 25646 close(2) = 0
> 25645 <... select resumed> ) = 1 (in [3])
> 25646 rt_sigaction(SIGHUP, {SIG_IGN, [HUP], SA_RESTART}, <unfinished ...>
> 25645 read(3, <unfinished ...>
> 25646 <... rt_sigaction resumed> {SIG_IGN, [], 0}, 8) = 0
> 25645 <... read resumed> 0xf77a91c0, 8192) = -1 EIO (Input/output error)
> 25646 vhangup( <unfinished ...>
> 25645 select(4, [0 3], [], [0], NULL) = 1 (in [3])
> 25645 read(3, "\3", 8192) = 1
> 25645 select(1, [0], [0], [0], NULL) = 1 (out [0])
> 25645 send(0, "\377", 1, MSG_OOB) = 1
> 25645 select(1, [0], [0], [0], NULL) = 1 (out [0])
> 25645 write(0, "\362", 1) = 1
> 25645 select(4, [0 3], [], [0], NULL) = 1 (in [3])
> 25645 read(3, 0xf77a91c0, 8192) = -1 EIO (Input/output error)
> <-- this is fatal
>
> This used to work at least in fc14, but in fc18 it seems broken. It
> happens intermittently.
>
> The following thread caught my eye
>
> https://lkml.org/lkml/2012/6/4/495
>
> After removing the three close() functions before vhangup(), this
> problem seems to go away. I suspect that this change caused bad
> interaction between in.telnetd and login. The extra closes seem to
> introduce EIO after something can be read from the pty master
> descriptor. Now, you can argue that the bug should be in in.telnetd,
> but I am not sure we want to break all the applications that depend on
> the old login behavior.
>
> I'd like to raise it to your attention and hear what you think the right fix is.
>
> Hua Zhong
>
> PS: Attached is the code snippet in login.c:
>
> tcgetattr(0, &tt);
> ttt = tt;
> ttt.c_cflag &= ~HUPCL;
>
> if ((fchown(0, 0, 0) || fchmod(0, cxt->tty_mode)) && errno != EROFS) {
>
> syslog(LOG_ERR, _("FATAL: %s: change permissions failed: %m"),
> cxt->tty_path);
> sleepexit(EXIT_FAILURE);
> }
>
> /* Kill processes left on this tty */
> tcsetattr(0, TCSANOW, &ttt);
>
> /*
> * Let's close file decriptors before vhangup
> * https://lkml.org/lkml/2012/6/5/145
> */
> close(STDIN_FILENO);
> close(STDOUT_FILENO);
> close(STDERR_FILENO);
>
> signal(SIGHUP, SIG_IGN); /* so vhangup() wont kill us */
> vhangup();
> signal(SIGHUP, SIG_DFL);
>
> /* open stdin,stdout,stderr to the tty */
> open_tty(cxt->tty_path);
>
> /* restore tty modes */
> tcsetattr(0, TCSAFLUSH, &tt);
>
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
