Hi. It looks like same issue is present in rhel6.8 build with xinetd.

Works for me:
util-linux-ng-2.17.2-12.18.el6.x86_64

Don't work for me:
util-linux-ng-2.17.2-12.20.el6.x86_64


+++ This bug was initially created as a clone of Bug #962145 +++

Description of problem: 

[root@localhost system]# telnet localhost
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Fedora release 19 (Schrödinger’s Cat)
Kernel 3.9.1-301.fc19.x86_64 on an x86_64 (2)
Connection closed by foreign host.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. install telnet-server-0.17-56.fc19
2. systemctl start telnet.socket
3. try to telnet to the locahost
  
Actual results:


Expected results:


Additional info: if you add -D options to the in.telnetd line in telnet@.service the connection will be made.

--- Additional comment from Michal Sekletar on 2013-05-13 08:24:07 EDT ---

I reproduced this bug, but it is not always the case that connection is closed immediately. Sometimes I am able to login. I installed older package telnet-server-0.17-55.fc19.x86_64 which uses xinetd activation and result was the same.
 
Everything works correctly in Fedora 18 regardless of activation mechanism. I think we are hitting bug in some other component than telnet-server. Not sure about right component tough.

--- Additional comment from Ed Greshko on 2013-05-13 08:30:07 EDT ---

Have a look at https://bugzilla.redhat.com/show_bug.cgi?id=904182

It may be tied to the same component.

--- Additional comment from Michal Sekletar on 2013-05-14 08:36:12 EDT ---

Looks like that telnet is broken because of the change in util-linux. Karel Zak already committed the fix to the upstream git repository[1]. I tried to replace the login binary with the newest one and it fixed the problem for me. Ed it would be great if you could try it out and confirm that it fixed the issue.

[1] https://github.com/karelzak/util-linux

--- Additional comment from Ed Greshko on 2013-05-14 10:11:22 EDT ---

Sadly I'm not conversant in github and don't know the process to obtain a new login binary to test.  (I test out of koji)

If you point me to a link which describes the process, I'd be happy to do it in my AM. (GMT+8).

--- Additional comment from Karel Zak on 2013-05-14 10:41:32 EDT ---

(In reply to comment #4)
> Sadly I'm not conversant in github

 git clone https://github.com/karelzak/util-linux.git
 cd util-linux
 ./autogen.sh
 ./confugure
 make login

 cp /usr/bin/login /usr/bin/login.org
 cp login /usr/bin/login

.. or be patient, I'm going to release v2.23.1 next week with the bugfix.

--- Additional comment from Ed Greshko on 2013-05-14 11:03:00 EDT ---

Being patient is not one of my virtues.  :-)

After resolving missing pieces it get.....

[egreshko@localhost util-linux]$ make login
  CCLD     login
gcc: fatal error: no input files
compilation terminated.
make: *** [login] Error 4

A simple "make" builds plenty of stuff like fsck, lscpu and others....  But no login.

--- Additional comment from Karel Zak on 2013-05-14 15:24:33 EDT ---

(In reply to comment #6)
> Being patient is not one of my virtues.  :-)

then you have to learn new things :-) lesson 2: see ./configure output, I guess you don't have installed pam-devel.

--- Additional comment from Ed Greshko on 2013-05-14 17:37:10 EDT ---

Thanks for that....  Building "login" worked but things are still not well.....

-rwxr-xr-x. 1 root root 112947 May 15 05:29 login
-rwxr-xr-x. 1 root root  40264 May 15 05:29 login.org

egreshko@localhost bin]$ telnet localhost
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Fedora release 19 (Schrödinger’s Cat)
Kernel 3.9.1-301.fc19.x86_64 on an x86_64 (5)
Connection closed by foreign host.

and from another system....

[egreshko@meimei ~]$ telnet 192.168.0.158
Trying 192.168.0.158...
Connected to 192.168.0.158.
Escape character is '^]'.
Fedora release 19 (Schrödinger’s Cat)
Kernel 3.9.1-301.fc19.x86_64 on an x86_64 (5)
Connection closed by foreign host.

--- Additional comment from Karel Zak on 2013-06-04 07:05:15 EDT ---

It seems that something is wrong with interaction between telnetd and vhangup() code in login(1).

login(1) closes all terminal file descriptors before it calls vhangup() -- this thing is probably incorrectly interpreted by telnetd as end of the session and all is terminated (SIGTERM).

If I remove the close() code from login(1) than all work as expected. See the code:

https://github.com/karelzak/util-linux/blob/master/login-utils/login.c#L404


Note that old xinetd based solution does not have this problem, the *same* login(1) binary works as expected with old telnetd+xinetd on F18. 

It's also possible that the problem is with 3.9 kernel, it would be nice to try to use f19 kernel in f18 with xinetd.

See also:
https://lkml.org/lkml/2012/6/5/145
https://lkml.org/lkml/2013/1/15/641
https://bugzilla.redhat.com/show_bug.cgi?id=904182

--- Additional comment from Karel Zak on 2013-06-05 03:50:55 EDT ---

I have tried to update kernel on my system and all works as expected with kernel-3.9.4 + xinetd + login from util-linux 2.23. 

So it does not seem like kernel problem.

--- Additional comment from Karel Zak on 2013-06-05 04:07:54 EDT ---

OK, another hint -- all works as expected if I install telnet-server (with socket activation) and login(1) from f19 to f18.

$ rpm -q systemd telnet-server; uname -r               
systemd-201-2.fc18.7.x86_64
telnet-server-0.17-56.fc19.x86_64
3.9.4-200.fc18.x86_64

--- Additional comment from Karel Zak on 2013-06-05 08:10:00 EDT ---

I think I found the problem:

code:
        ttt.c_cflag &= ~HUPCL;
        tcsetattr(0, TCSAFLUSH, &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);


f18:
    
ioctl(0, SNDCTL_TMR_CONTINUE or SNDRV_TIMER_IOCTL_GPARAMS or TCSETSF, {B9600 opost isig icanon 
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
rt_sigaction(SIGHUP, {SIG_IGN, [HUP], SA_RESTORER|SA_RESTART, 0x3c95c35c20}, {SIG_IGN, [], 0}, 
vhangup()                               = 0
--- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} ---
--- SIGCONT {si_signo=SIGCONT, si_code=SI_KERNEL} ---
rt_sigaction(SIGHUP, {SIG_DFL, [HUP], SA_RESTORER|SA_RESTART, 0x3c95c35c20}, {SIG_IGN, [HUP], S
open("/dev/pts/4", O_RDWR|O_NONBLOCK)   = 0
    

f19:
 
ioctl(0, SNDCTL_TMR_CONTINUE or SNDRV_TIMER_IOCTL_GPARAMS or TCSETSF, {B9600 opost isig icanon 
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
--- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} ---
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
+++ killed by SIGTERM +++


The problem is TCSAFLUSH, because it postpone the action and we get SIGHUP and SIGTERM before we setup signal(SIGHUP, SIG_IGN). The solution is to use TCSANOW and probably also move signal(SIGHUP, SIG_IGN) before we close the std{out,in,err}.

--- Additional comment from Fedora Update System on 2013-06-05 09:30:05 EDT ---

util-linux-2.23.1-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/util-linux-2.23.1-2.fc19

--- Additional comment from Ed Greshko on 2013-06-05 11:04:06 EDT ---

Confirmed Fix and gave karma ....  Thanks....

--- Additional comment from Fedora Update System on 2013-06-05 12:51:45 EDT ---

Package util-linux-2.23.1-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing util-linux-2.23.1-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10075/util-linux-2.23.1-2.fc19
then log in and leave karma (feedback).

--- Additional comment from Michal Sekletar on 2013-06-06 07:17:56 EDT ---

I tested the update and it resolved the issue. Thanks.

--- Additional comment from Fedora Update System on 2013-06-07 00:37:02 EDT ---

util-linux-2.23.1-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.