[Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on HP-UX11i

Wed Oct 1 06:11:03 EDT 2003

Bugs item #812376, was opened at 2003-09-25 12:10
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).

import ftplib

f = ftplib.FTP()

f.connect('hostname', 21)

this raises:

socket.gaierror: (8, 'host nor service provided, or not 

known')

In FTP.connect() it is the call to socket.getaddrinfo() 

that is raising the exception.

The same code works OK on Python 2.2.1

If I pass an IP address instead of a hostname, the code 

runs OK on Python 2.3

----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2003-10-01 11:11

Message:
Logged In: YES 
user_id=200117

I tried dropping different versions of socketmodule.c & 

socketmodule.h into Python-2.3.1 and re-building.

The earliest version of socketmodule.c I could build & run was 

1.219 and this does raise the exception for a hostname that 

needs to be resolved via NIS.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 15:48

Message:
Logged In: YES 
user_id=29957

Darn. There's probably something Not Quite Right with how

socketmodule.c interacts with HP/UX's NIS, then. I'm not

sure what the problem would be, and I don't have access to a

HP/UX box that uses NIS for hostnames, so I'm not able to

help... 

As previously mentioned, there's a _lot_ of changes been

made to socketmodule.c between 2.2 and 2.3. If you're

CVS-savvy, you might like to try checking out different

versions between 2.200 (the version in 2.2) and 2.270 (the

version in 2.3) to narrow down exactly when the module stops

working.

One thing - "_" isn't supposed to be legal in domain names,

I don't know if that's related (although the other name has

no underscores...)

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 14:56

Message:
Logged In: YES 
user_id=200117

The hostnames I have tried are 'tate_mod' and 'rosalind'.

Lookup is by NIS. I can ping and remote login to these 

workstations using their hostnames.

I have since discovered that if I add an entry to /etc/hosts 

specifying a different hostname 'fred' and rosalind's IP 

address, then f.connect('fred', 21) doesn't give the error.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 14:01

Message:
Logged In: YES 
user_id=29957

Hm. What's the actual hostname you're trying? I can't get

this failure on HP/UX 11.11, using the HP testdrive box. 

Are you using NIS or some other non-standard method of

hostname lookup? The problem is that there's a fair bit

changed between 2.2 and 2.3's socket module (there was 71

different checkins).

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 13:21

Message:
Logged In: YES 
user_id=200117

Apologies for not being clear.

I actually used the real hostname (in quotes) of a workstation 

on our local network in place of 'hostname'.

If I use 'localhost' or the hostname of the workstation the 

application is running on, I don't get the error.

If I use the hostname of any other workstation on the local 

network, I do get the error.

Running exactly the same code on Python 2.2.1 works OK for 

all hostnames.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 10:44

Message:
Logged In: YES 
user_id=29957

Using the HP testdrive system

HP-UX spe169 B.11.11 U 9000/800 1939057856 unlimited-user

license

I did the following with 2.3.2c1:

>>> import ftplib

>>> f = ftplib.FTP()

>>> f.connect('localhost', 21)

'220 spe169.testdrive.hp.com FTP server (Version

1.1.214.4(PHNE_27765) Wed Sep  4 05:59:34 GMT 2002) ready.'

>>> 

Ah. In your example, you have 'hostname'. Is that

_literally_ what you typed? If so, it's looking for a

machine called 'hostname'. I tried that, and got the same

error you got. 

Try it without the single quotes around 'hostname'. 

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:50

Message:
Logged In: YES 
user_id=29957

Hm. I'm obviously having reading difficulties. There's

obviously something else going on entirely. Damn. I will try

to grab some time on one of the HP test boxes to see if I

can figure what's going on...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd

work for 2.3 and not 2.3.1, unless 2.3.1's script was

generated with a newer version of autoconf - aha. Yes, it was. 

If you could check if the fix in 

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470

"makes it all better", that would be great. Put aclocal.m4

alongside configure &c, re-run autoconf, then ./configure ; make

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-26 18:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.

I don't think configure was broken with Python 2.3 - and it 

was with 2.3 that I first noticed the problem.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.

Can you apply the workaround from

http://www.python.org/2.3.1/bugs.html and see if the problem

is fixed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470