Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 55172 - in.ftpd: libwrap.so.1.1: No such file
in.ftpd: libwrap.so.1.1: No such file
Product: Red Hat Linux
Classification: Retired
Component: ftp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Depends On:
  Show dependency treegraph
Reported: 2001-10-26 12:02 EDT by Bertil Askelid
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-26 12:02:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bertil Askelid 2001-10-26 12:02:47 EDT
Description of Problem:

~> \ftp ftp.zedz.net
Connected to ftp.zedz.net.
/usr/libexec/ld.so: in.ftpd: libwrap.so.1.1: No such file or directory
Name (ftp.zedz.net:bertil): anonymous
421 Service not available, remote server has closed connection
Login failed.
No control connection for command: No such file or directory

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


How Reproducible:

This happens for the ftp.zedz.net site when it is down. Then it quickly
responds most of the time with 

	421 Service not available, remote server has closed connection

but sometimes it doesn't and let you in to a login prompt. At those times,
the libwrap.so.1.1 presence is requested.

Steps to Reproduce:
1. ftp ftp.zedz.net

Actual Results:

Expected Results:

Additional Information:
Comment 1 Bernhard Rosenkraenzer 2001-10-30 07:31:18 EST
This is a bug in the server, not the client.
We don't ship libwrap, and never did.

My take of what's happening:

The ftp server machine is out of file handles, therefore it can't open all 
libraries ftpd is linked to (on the server machine), causing this error 
message. Since ftpd is run through (x)inetd, the message ends up on the 
client's screen rather than somewhere on the server.

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