Bug 211776 - xinetd in an endless loop after spawning tftpd
xinetd in an endless loop after spawning tftpd
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xinetd (Show other bugs)
5
ppc64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Safranek
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-22 12:16 EDT by Alexey Bozrikov
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: xinetd-2.3.14-9.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-22 02:44:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xinetd debug session and process info (3.15 KB, text/plain)
2006-10-24 03:39 EDT, Alexey Bozrikov
no flags Details
Patch to replace int with ssize_t (20.31 KB, patch)
2006-10-31 16:58 EST, Jay Fenlason
no flags Details | Diff

  None (edit)
Description Alexey Bozrikov 2006-10-22 12:16:18 EDT
Description of problem:
after using tftp service xinetd falls into an endless loop eating CPU cycles 
and not answering requests

Version-Release number of selected component (if applicable):
xinetd-2.3.13-6.2.1
tftp-server-0.41-1.2.1
kernel:  2.6.18-1.2200.fc5 #1 SMP Sat Oct 14 17:08:02 EDT 2006 ppc64 ppc64 
ppc64 GNU/Linux

How reproducible:
always

Steps to Reproduce:
1. enable tftp service in /etc/xinetd.d
2. upload something via tftp over the network
3.
  
Actual results:
xinetd loops

Expected results:
normal xinetd operation

Additional info:
waited for about 24 hours to see if xinetd will get back to normal operation to 
no avail. 'service xinetd restart' restores normal operation.
tftp service description:
service tftp
{
        disable = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /tftpboot
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

This bug is POSSIBLY a duplicate of Bug 124704, but latter has no description 
and reported for RH AS 2.1
Comment 1 Jay Fenlason 2006-10-23 10:37:41 EDT
Can you install the xinetd-debuginfo rpm, trigger the bug, and attach to the 
looping xinetd with gdb?  I'd like to know exactly where it's looping. 
 
I'm chasing a bug where xinetd starts looping if you tell xinetd to reload is 
services while it's got a server running, but it sounds like something 
different from this. 
Comment 2 Alexey Bozrikov 2006-10-24 03:04:12 EDT
While xinetd is looping I attached to the process with gdb and did few single 
steps. Session log is attached. Few more comments: after detaching process from 
gdb (just quit at (gdb) prompt) xinetd exited silently, so I had to restart the 
service.

[quote]
root@lnxsrv tftpboot# gdb /usr/sbin/xinetd 927

GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "ppc64-redhat-linux-gnu"...Using host libthread_db 
library "/lib64/libthread_db.so.1".

Attaching to program: /usr/sbin/xinetd, process 927
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x100000
`shared object read from target memory' has disappeared; keeping its symbols.
Loaded symbols for /usr/sbin/xinetd
Reading symbols from /usr/lib/libwrap.so.0...done.
Loaded symbols for /usr/lib/libwrap.so.0
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2

(gdb) step
Single stepping until exit from function call___do_global_ctors_aux,
which has no line number information.
0x07dacd10 in recv () from /lib/libc.so.6
(gdb)
Single stepping until exit from function recv,
which has no line number information.
0x07cdd570 in __syscall_error () from /lib/libc.so.6
(gdb)
Single stepping until exit from function __syscall_error,
which has no line number information.
drain (sd=5) at util.c:246
246        } while (cc > 0);
(gdb)
35        return __recv_alias (__fd, __buf, __n, __flags);
(gdb)
0x08026490 in call___do_global_ctors_aux () from /usr/sbin/xinetd
(gdb)
Single stepping until exit from function call___do_global_ctors_aux,
which has no line number information.
0x07dacd10 in recv () from /lib/libc.so.6
(gdb)
Single stepping until exit from function recv,
which has no line number information.
0x07cdd570 in __syscall_error () from /lib/libc.so.6
(gdb)
Single stepping until exit from function __syscall_error,
which has no line number information.
drain (sd=5) at util.c:246
246        } while (cc > 0);
(gdb)
35        return __recv_alias (__fd, __buf, __n, __flags);
(gdb)
0x08026490 in call___do_global_ctors_aux () from /usr/sbin/xinetd
(gdb)
Single stepping until exit from function call___do_global_ctors_aux,
which has no line number information.
0x07dacd10 in recv () from /lib/libc.so.6
(gdb)
Single stepping until exit from function recv,
which has no line number information.
0x07cdd570 in __syscall_error () from /lib/libc.so.6
(gdb)
Single stepping until exit from function __syscall_error,
which has no line number information.
drain (sd=5) at util.c:246
246        } while (cc > 0);
(gdb)
35        return __recv_alias (__fd, __buf, __n, __flags);
(gdb)
[unquote]
Comment 3 Alexey Bozrikov 2006-10-24 03:39:11 EDT
Created attachment 139199 [details]
xinetd debug session and process info
Comment 4 Alexey Bozrikov 2006-10-24 03:40:34 EDT
Some more information attached in the file (process status, CPU usage and 
another debug session with backtrace). More comments: xinetd DOES NOT fall in 
an endless loop immediately, I have tried few subsequent tftp sessions and they 
all worked OK, but after 2-3 minutes xinetd had fallen into loop again. Again, 
if attaching to normally running xinetd with gdb and then detaching - the 
process continues to run normally, but if I attach to a looping one and then 
detach after few `step' commands - it exits silently.
Comment 5 Jay Fenlason 2006-10-25 22:06:52 EDT
It looks like upstream doesn't understand that there are platforms where 
ssize_t and int are different sizes.  I'm going to do a scan and see if there 
are any other places where he makes this kind of mistake. 
Comment 6 Jay Fenlason 2006-10-31 16:59:00 EST
Created attachment 139904 [details]
Patch to replace int with ssize_t
Comment 7 Jay Fenlason 2006-10-31 17:00:14 EST
Here's a patch that makes xinetd use ssize_t and size_t instead of int where  
appropriate.  While I was poking through the code I also found the problems  
that lead to bz#213311 and it's attached patch. 
Comment 8 Fedora Update System 2007-05-21 18:26:45 EDT
xinetd-2.3.14-9.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.