Bug 82287 - in.tftpd: Cannot bind to local socket
in.tftpd: Cannot bind to local socket
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: tftp (Show other bugs)
7.3
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Elliot Lee
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-20 17:15 EST by Mark H Johnson
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-19 17:43:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark H Johnson 2003-01-20 17:15:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.16-bigphys i686)

Description of problem:
Upgraded a Red Hat 7.1 system to 7.3 and tftp server no longer works.
I already read bugs 65476, 67524, and 55789. I can't tell for sure
if my problem is exactly the same or not. I can work around the
problem by backing up to the older version of /usr/sbin/in.tftpd
as suggested by one of the comments. I have not tried the version
in RawHide.

I am not using IPv6 (or I don't think I am ...), just trying to
get a PXE client up and running - using SystemImager to clone PC
configurations.


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


How reproducible:
Always

Steps to Reproduce:
1. Start xinetd
2. Start PXE client
3. Watch the error messages come out
    

Actual Results:  Error messages as noted in additional information

Expected Results:  Files downloaded to PXE client.

Additional info:


Some supporting data follows:

From /var/log/messages
Jan 20 15:41:28 cpc4 xinetd[2928]: xinetd Version 2.3.7 started with libwrap
options compiled in.
Jan 20 15:41:28 cpc4 xinetd[2928]: Started working: 16 available services
Jan 20 15:41:30 cpc4 xinetd: xinetd startup succeeded
Jan 20 15:42:37 cpc4 dhcpd: DHCPDISCOVER from 00:20:ed:24:d2:59 via eth0
Jan 20 15:42:37 cpc4 dhcpd: DHCPOFFER on 192.168.50.11 to 00:20:ed:24:d2:59 via
eth0
Jan 20 15:42:39 cpc4 dhcpd: DHCPREQUEST for 192.168.50.11 from 00:20:ed:24:d2:59
via eth0
Jan 20 15:42:39 cpc4 dhcpd: DHCPACK on 192.168.50.11 to 00:20:ed:24:d2:59 via
eth0
Jan 20 15:42:39 cpc4 dhcpd: DHCPREQUEST for 192.168.50.11 from 00:20:ed:24:d2:59
via eth0
Jan 20 15:42:39 cpc4 dhcpd: DHCPACK on 192.168.50.11 to 00:20:ed:24:d2:59 via
eth0
Jan 20 15:42:40 cpc4 in.tftpd[2934]: cannot bind to local socket: Address
already in use
[this last message repeats over 20 times]
Jan 20 15:42:40 cpc4 xinetd[2928]: Deactivating service tftp due to excessive
incoming connections.  Restarting in 30 seconds.
Jan 20 15:43:10 cpc4 xinetd[2928]: Activating service tftp
Jan 20 15:43:13 cpc4 ftpd[2959]: wu-ftpd - TLS settings: control allow,
client_cert allow, data allow
Jan 20 15:43:13 cpc4 ftpd[2959]: FTP session closed
Jan 20 15:48:13 cpc4 ftpd[3004]: wu-ftpd - TLS settings: control allow,
client_cert allow, data allow
Jan 20 15:48:13 cpc4 ftpd[3004]: FTP session closed

/etc/sysconfig/network
NETWORKING=yes
HOSTNAME="cpc4"
GATEWAY="192.52.216.248"
GATEWAYDEV="eth1"
FORWARD_IPV4="no"
NISDOMAIN="gsde.hou.us.ray.com"

/etc/xinetd.d/tftp
# default: off
# description: The tftp server serves files using the trivial file transfer
#       protocol.  The tftp protocol is often used to boot diskless
#       workstations, download configuration files to network-aware printers,
#       and to start the installation process for some operating systems.
service tftp
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /tftpboot -r blksize -l
        disable                 = no
        flags                   = IPv4
}

[note the flags line added per the comment noted on one of the other
bugs - it didn't help]
Comment 1 Elliot Lee 2003-01-29 08:51:04 EST
Run 'fuser -uv 69/udp' as root, and find out what is already using the port.
Comment 2 Mark H Johnson 2003-01-29 09:11:22 EST
Output from fuser -uv 69/udp...
          USER      PID ACCESS COMMAND
69/udp    root      951 f....  xinetd
Comment 3 Elliot Lee 2003-02-19 17:43:39 EST
That -l in the server_args is probably the problem - it is not present in the
default 7.3 configuration file, and it doesn't make sense to use with inetd.

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