ftp problem with rh 7.1

ftp problem with rh 7.1

Post by Scott Ballinge » Mon, 28 Jul 2003 07:27:50



Not a d3 issue, but I need some help, and have spent the last hour
googling for some clue without success...

I am having a problem with ftp on rh 7.1 (system is d3 7.2.1). Ftp
works fine for a few days after reboot, then stops: you can log in,
send password, then nothing.

ps -ef | grep ftp produces the following:

root  27951   1  0 Jul25 ?   00:00:00 ftpd: ??: connected: IDLE
root  29036   1  0 Jul25 ?   00:00:00 ftpd: localhost: connected: IDLE
root  29038   1  0 Jul25 ?   00:00:00 ftpd: localhost: connected: IDLE
root  31690 29700  0 Jul25 ? 00:00:00 ftpd: ftp: connected: IDLE

pid 29700 is xinetd.

I cannot 'kill -9' the ftpd sessions!?

Any help here will be greatly appreciated!

--
Scott Ballinger
Pareto Corporation
Edmonds WA  USA
425-670-0831

 
 
 

ftp problem with rh 7.1

Post by Jeffrey Kaufma » Mon, 28 Jul 2003 08:54:24


I agree with you that this is not a D3 problem. It may not be a Linux
problem either. I have customers running on the same version of D3 and Red
Hat as you using ftp daily for months at a time.

Think about what happens in a reboot. ftp is shut down and started. But so
are a number of other processes.

Sorry I can't be of more help for your Saturday afternoon.
--

Jeffrey Kaufman
Key Data Systems Group
www.keydata.us
559-432-3832
559-432-4657 fax

Western Pacific Supply
www.westpacsupply.com
888-WestPac


Quote:> Not a d3 issue, but I need some help, and have spent the last hour
> googling for some clue without success...

> I am having a problem with ftp on rh 7.1 (system is d3 7.2.1). Ftp
> works fine for a few days after reboot, then stops: you can log in,
> send password, then nothing.

> ps -ef | grep ftp produces the following:

> root  27951   1  0 Jul25 ?   00:00:00 ftpd: ??: connected: IDLE
> root  29036   1  0 Jul25 ?   00:00:00 ftpd: localhost: connected: IDLE
> root  29038   1  0 Jul25 ?   00:00:00 ftpd: localhost: connected: IDLE
> root  31690 29700  0 Jul25 ? 00:00:00 ftpd: ftp: connected: IDLE

> pid 29700 is xinetd.

> I cannot 'kill -9' the ftpd sessions!?

> Any help here will be greatly appreciated!

> --
> Scott Ballinger
> Pareto Corporation
> Edmonds WA  USA
> 425-670-0831


 
 
 

ftp problem with rh 7.1

Post by Mark Taylo » Mon, 28 Jul 2003 09:18:54




Quote:> Not a d3 issue, but I need some help, and have spent the last hour
> googling for some clue without success...

> I am having a problem with ftp on rh 7.1 (system is d3 7.2.1). Ftp
> works fine for a few days after reboot, then stops: you can log in,
> send password, then nothing.

> ps -ef | grep ftp produces the following:

> root  27951   1  0 Jul25 ?   00:00:00 ftpd: ??: connected: IDLE
> root  29036   1  0 Jul25 ?   00:00:00 ftpd: localhost: connected: IDLE
> root  29038   1  0 Jul25 ?   00:00:00 ftpd: localhost: connected: IDLE
> root  31690 29700  0 Jul25 ? 00:00:00 ftpd: ftp: connected: IDLE

> pid 29700 is xinetd.

> I cannot 'kill -9' the ftpd sessions!?

> Any help here will be greatly appreciated!

You should only have to restart xinetd, not reboot the machine. I'm
wondering though, why it says localhost is connected to itself? I honestly
haven't bothered to monitor the processes while the ftpd in in use, but
what possible reason could there be for localhost to be connecting to
itself?

What is in /etc/xinetd.d/wu-ftpd
What is in /etc/ftpaccess

That may offer some hints.

Mark

 
 
 

ftp problem with rh 7.1

Post by Doug Dumitr » Mon, 28 Jul 2003 14:55:56




Quote:>Not a d3 issue, but I need some help, and have spent the last hour
>googling for some clue without success...

>I am having a problem with ftp on rh 7.1 (system is d3 7.2.1). Ftp
>works fine for a few days after reboot, then stops: you can log in,
>send password, then nothing.

>ps -ef | grep ftp produces the following:

>root  27951   1  0 Jul25 ?   00:00:00 ftpd: ??: connected: IDLE
>root  29036   1  0 Jul25 ?   00:00:00 ftpd: localhost: connected: IDLE
>root  29038   1  0 Jul25 ?   00:00:00 ftpd: localhost: connected: IDLE
>root  31690 29700  0 Jul25 ? 00:00:00 ftpd: ftp: connected: IDLE

>pid 29700 is xinetd.

>I cannot 'kill -9' the ftpd sessions!?

>Any help here will be greatly appreciated!

Here are some other things to look at:

  netstat -aNp - see what processes are talking to who

  lsof -p pid  - see what files (and sockets) each processes has open

In particular, lsof can tell you a lot about what a process is doing.

You can also try:

  strace -p pid - see what system calls a process is making

'strace' is a pretty "advanced" command and can often spit out reams
of output (set your terminal scroll back to 5000+ lines).  It
basically shows every system call that a process makes to the kernel.
This is really quite helpful for a 'd3' install that refuses to run
and the boot error message isn't much help.  strace can often tell you
system actual system call that failed and be of great help in tracking
down problems.

Doug Dumitru
EasyCo LLC
610 237-2000
http://easyco.com

 
 
 

ftp problem with rh 7.1

Post by Scott Ballinge » Tue, 29 Jul 2003 09:57:49


Hi all & thanks, but...

1. restarting xinetd does not fix the problem.
2. ftpd: localhost:... is the result of a hung "ftp localhost"
command, same as "ftp thomas" (this host name) or "ftp 192.1.1.2".
3. the result of lsof produces another hung process that cannot be killed:


<snipped to show yet another hung ftp session>
root  318 32763  0 17:42 ?   00:00:00 ftpd: thomas: connected: IDLE


<nothing, then ^\ resulting in core dump...>


root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318



pick     28389 28361  0 Jul24 pts/101  00:01:00 d3 -dcdon
root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318
root       408 32707  0 17:50 pts/19   00:00:00 grep 389

Still fiddling....

Scott Ballinger
Pareto Corporation
Edmonds WA USA
425-670-0831


> Here are some other things to look at:

>   netstat -aNp - see what processes are talking to who

>   lsof -p pid  - see what files (and sockets) each processes has open

> In particular, lsof can tell you a lot about what a process is doing.

> You can also try:

>   strace -p pid - see what system calls a process is making

> 'strace' is a pretty "advanced" command and can often spit out reams
> of output (set your terminal scroll back to 5000+ lines).  It
> basically shows every system call that a process makes to the kernel.
> This is really quite helpful for a 'd3' install that refuses to run
> and the boot error message isn't much help.  strace can often tell you
> system actual system call that failed and be of great help in tracking
> down problems.

> Doug Dumitru
> EasyCo LLC
> 610 237-2000
> http://easyco.com

 
 
 

ftp problem with rh 7.1

Post by Doug Dumitr » Tue, 29 Jul 2003 10:11:36




Quote:>Hi all & thanks, but...

>1. restarting xinetd does not fix the problem.
>2. ftpd: localhost:... is the result of a hung "ftp localhost"
>command, same as "ftp thomas" (this host name) or "ftp 192.1.1.2".
>3. the result of lsof produces another hung process that cannot be killed:

If lsof is*, this implies that you have a DNS problem.  lsof
tries to resolve IP addresses into names.  You can add the -n option
and DNS resolution will be skipped.

On the other hand, lack of DNS resolution can make a lot of stuff
experience really weird timeouts.  I would look into this.


><snipped to show yet another hung ftp session>
>root  318 32763  0 17:42 ?   00:00:00 ftpd: thomas: connected: IDLE


><nothing, then ^\ resulting in core dump...>


>root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318



>pick     28389 28361  0 Jul24 pts/101  00:01:00 d3 -dcdon
>root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318
>root       408 32707  0 17:50 pts/19   00:00:00 grep 389

>Still fiddling....

>Scott Ballinger
>Pareto Corporation
>Edmonds WA USA
>425-670-0831

Doug Dumitru
EasyCo LLC
610 237-2000
http://www.veryComputer.com/
 
 
 

ftp problem with rh 7.1

Post by Steve Lancou » Tue, 29 Jul 2003 10:42:16



> Hi all & thanks, but...

> 1. restarting xinetd does not fix the problem.
> 2. ftpd: localhost:... is the result of a hung "ftp localhost" command,
> same as "ftp thomas" (this host name) or "ftp 192.1.1.2".
> 3. the result of lsof produces another hung process that cannot be killed:


> <snipped to show yet another hung ftp session>
> root  318 32763  0 17:42 ?   00:00:00 ftpd: thomas: connected: IDLE


> <nothing, then ^\ resulting in core dump...>


> root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318



> pick     28389 28361  0 Jul24 pts/101  00:01:00 d3 -dcdon
> root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318
> root       408 32707  0 17:50 pts/19   00:00:00 grep 389

> Still fiddling....

> Scott Ballinger
> Pareto Corporation
> Edmonds WA USA
> 425-670-0831

Scott,

Can you post the contents of /etc/resolv.conf (hide the actual dns
server IP addresses in your post but check them yourself to see that
they're correct).

Are you really ftp'ing to localhost in your application or were you just
using that to test or illustrate the problem?

I notice in your post you equate "localhost", "thomas" and "192.1.1.2".
  Is 192.1.1.2 an address that you "own"?  Is this machine connected to
the internet?  (If the machine is connected to the internet, is
configured with address 192.1.1.2 and 192.1.1.2 isn't really "yours",
this might produce the result you're seeing.)

Are you able to ping localhost or thomas or 192.1.1.2?

You might try ftp -v and see if the ftp's verbose mode reveals anything
interesting.

Hope some of the above helps.

Steve Lancour

 
 
 

ftp problem with rh 7.1

Post by Scott Ballinge » Tue, 29 Jul 2003 13:17:06


Doug,

lsof -np pid produced another hung process that cannot be killed:


root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318
root      1990     1  0 20:23 pts/5    00:00:00 lsof -np 318
root      2167  1957  0 20:33 pts/5    00:00:00 grep lsof


root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318
root      1990     1  0 20:23 pts/5    00:00:00 lsof -np 318
root      2169  1957  0 20:33 pts/5    00:00:00 grep lsof

I don't think this is a dns problem, because I can:
ping localhost
ping thomas
ping u.washington.edu, easyco.com, etc.

I can also
ftp localhost
ftp thomas
ftp another-host-in-this-domain

(Of course, I can also do all of the above via ip address as well.)

I can ssh to this host & other hosts.
Can ftp to other hosts from this host.
Cannot ftp to this host?!

Steve,

This network was set up as 192.1.1.xxx, instead of the usual
192.168.x.x. Internet access is via a NAT router/firewall.


search ccvcorp.com
nameserver 209.20.130.33 <-- these are the isp's dns nameservers
nameserver 209.20.130.35


Connected to thomas.
220 thomas FTP server (Version wu-2.6.1-16) ready.
Name (thomas:pick): asb
331 Password required for asb.
Password:
[^\ entered here after password entered, then waiting > 1 minute>]

Quit (core dumped)

So, because all other known network services seem to work fine, but
ftp does not (I cannot ftp to myself, or to this host from anywhere
else), I believe this is a ftpd problem. Restarting xinetd does not
fix it. Therefore I will investigate ftp configuration issues?

(Why does it work for a few days after booting and then stop?)

--
Scott Ballinger
Pareto Corporation
Edmonds WA  USA
425-670-0831


> If lsof is*, this implies that you have a DNS problem.  lsof
> tries to resolve IP addresses into names.  You can add the -n option
> and DNS resolution will be skipped.

> On the other hand, lack of DNS resolution can make a lot of stuff
> experience really weird timeouts.  I would look into this.

 
 
 

ftp problem with rh 7.1

Post by Mark Taylo » Tue, 29 Jul 2003 20:55:49




Quote:> Steve,

> This network was set up as 192.1.1.xxx, instead of the usual
> 192.168.x.x. Internet access is via a NAT router/firewall.

Isn't this your problem?  192.1.1.x is a routeable address and not in the
private address space.  How difficult would it be to change the network to
a 192.168.x.x range?

Mark

 
 
 

ftp problem with rh 7.1

Post by Steve Lancou » Tue, 29 Jul 2003 22:59:09



> Doug,

> lsof -np pid produced another hung process that cannot be killed:


> root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318
> root      1990     1  0 20:23 pts/5    00:00:00 lsof -np 318
> root      2167  1957  0 20:33 pts/5    00:00:00 grep lsof


> root       389     1  0 17:49 pts/19   00:00:00 lsof -p 318
> root      1990     1  0 20:23 pts/5    00:00:00 lsof -np 318
> root      2169  1957  0 20:33 pts/5    00:00:00 grep lsof

> I don't think this is a dns problem, because I can:
> ping localhost
> ping thomas
> ping u.washington.edu, easyco.com, etc.

> I can also
> ftp localhost
> ftp thomas
> ftp another-host-in-this-domain

> (Of course, I can also do all of the above via ip address as well.)

> I can ssh to this host & other hosts.
> Can ftp to other hosts from this host.
> Cannot ftp to this host?!

> Steve,

> This network was set up as 192.1.1.xxx, instead of the usual
> 192.168.x.x. Internet access is via a NAT router/firewall.


> search ccvcorp.com
> nameserver 209.20.130.33 <-- these are the isp's dns nameservers
> nameserver 209.20.130.35


> Connected to thomas.
> 220 thomas FTP server (Version wu-2.6.1-16) ready.
> Name (thomas:pick): asb
> 331 Password required for asb.
> Password:
> [^\ entered here after password entered, then waiting > 1 minute>]
> Quit (core dumped)

> So, because all other known network services seem to work fine, but ftp
> does not (I cannot ftp to myself, or to this host from anywhere else), I
> believe this is a ftpd problem. Restarting xinetd does not fix it.
> Therefore I will investigate ftp configuration issues?

> (Why does it work for a few days after booting and then stop?)

Scott,

192.1.1.2 is a "real" internet address (as opposed to the address blocks
reserved for internal network use).  Your NAT/router should have a
"real" IP address on its external interface but all of the machines on
the internal network (including the router's internal interface) need to
be assigned addresses within the blocks reserved for internal network
use.  These reserved blocks are ...

10.0.0.0   - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

... see http://www.faqs.org/rfcs/rfc1918.html for details.  I think
what's happening is when you reboot the machine it sends out rip packets
announcing itself as 192.1.1.2.  The NAT router receives these packets
and updates its routing tables accordingly.  For some period of time the
router sees your machine as 192.1.1.2 and everything works.  Sometime
later the routing tables in the router are updated with the "real"
192.1.1.2's information and your connections start failing.  You really
need to re-number your internal machines to use addresses from within
the reserved blocks.  Of course if 192.1.1.2 is really "yours" then
disregard this post.

Steve Lancour

 
 
 

ftp problem with rh 7.1

Post by kevin zollinge » Wed, 30 Jul 2003 00:22:57






>> Steve,

>> This network was set up as 192.1.1.xxx, instead of the usual
>> 192.168.x.x. Internet access is via a NAT router/firewall.

> Isn't this your problem?  192.1.1.x is a routeable address and not in
> the private address space.  How difficult would it be to change the
> network to a 192.168.x.x range?

I was all set to agree. I even had a description of how you can get around
the problem of having public IPs that you don't own on your network, but
then I re-read the last post from Scott.

Quote:> So, because all other known network services seem to work fine, but
> ftp does not (I cannot ftp to myself, or to this host from anywhere
> else), I believe this is a ftpd problem. Restarting xinetd does
> not fix it. Therefore I will investigate ftp configuration issues?

If you get on the box and find that you can't ftp 127.0.0.1 then we can
remove the network as the problem. Have you checked all the log files? Any
ftp messages there? If you have control of the server, have you loaded the
lastest version of the ftp server that you are using? Have you considered
using another ftp server? We use PureFTP and like it.
(http://www.pureftpd.org/) If you do a "telnet 127.0.0.1 20" what do you
get?

--
~ kevin zollinger

 
 
 

ftp problem with rh 7.1

Post by Vic Abe » Wed, 30 Jul 2003 01:05:29



> Doug,

> lsof -np pid produced another hung process that cannot be killed:
> ...

Besides DNS and service name blockages, which "-n" and "-P"
tell lsof to avoid, other blocks are possible, and they and
their work-arounds are documented in the lsof man page and
its FAQ.  They include UID to login name lookups (avoid with
"-l"), kernel name cache lookup problems (usually not on Linux,
avoid with "-C"), NFS file system stat(2) blocks (avoid with
"-b" and possible "-w").

Vic Abell, lsof author

 
 
 

ftp problem with rh 7.1

Post by Scott Ballinge » Wed, 30 Jul 2003 06:18:52


[snip]

Quote:> If you get on the box and find that you can't ftp 127.0.0.1 then we can
> remove the network as the problem. Have you checked all the log files? Any
> ftp messages there? If you have control of the server, have you loaded the
> lastest version of the ftp server that you are using? Have you considered
> using another ftp server? We use PureFTP and like it.
> (http://www.pureftpd.org/) If you do a "telnet 127.0.0.1 20" what do you
> get?

I probably should have made it clearer that "ftp 127.0.0.1" & "ftp localhost"
produced the same (bad) result.

I did look at the log files (xferlog) and figured out that it stopped
working last friday at 6:05am (last successful xfer), but other that that I
was not able to glean much from the logs.

As they say to med school students: "don't look for zebras when you hear
hoofbeats." Kevin's simplest advice seems to have solved the problem: I
downloaded an installed the latest rh7.1 rpm for wu-ftp, restarted xinetd
(maybe didn't need to do this?) and now everything works as it should. What
caused this problem in the first place? Who knows. Will it return (same as
before, after reboot)? We'll see...

Thanks,

Scott Ballinger
Pareto Corporation
Edmonds WA USA
425-670-0831

 
 
 

ftp problem with rh 7.1

Post by kevin zollinge » Wed, 30 Jul 2003 07:50:41






>> Doug,

>> lsof -np pid produced another hung process that cannot be killed:
>> ...

> Besides DNS and service name blockages, which "-n" and "-P"
> tell lsof to avoid, other blocks are possible, and they and
> their work-arounds are documented in the lsof man page and
> its FAQ.  They include UID to login name lookups (avoid with
> "-l"), kernel name cache lookup problems (usually not on Linux,
> avoid with "-C"), NFS file system stat(2) blocks (avoid with
> "-b" and possible "-w").

> Vic Abell, lsof author

Witness the power of che^H^H^H Open Source Software. Can you imagine Bill
Gates scanning usenet every day to see if there are questions related to
windows?

Wow.

I'll bet he'd even answer a question via email.

--
~ kevin zollinger

 
 
 

ftp problem with rh 7.1

Post by Vic Abe » Wed, 30 Jul 2003 22:15:50



> Witness the power of  Open Source Software. Can you imagine Bill
> Gates scanning usenet every day to see if there are questions related to
> windows?

> Wow.

> I'll bet he'd even answer a question via email.

Well I have no empire to run, no dragons to slay, no fair
maidens to rescue -- and I do answer direct e-mail about
lsof -- but lsof is a tad smaller than Windows or the
Microsoft juggernaut.  :-)

Vic Abell, lsof author

 
 
 

1. Problems starting OMS 2.2 on RH 7.1

Hi,

After some struggle I got Oracle 8.1.7.2 running on RH71, sigh....

Database, listener, agent and datagatherer work fine.

One problem left....... OMS

get these messages in log....

<BEGIN LOG>
Starting the management server at Thu Sep 13 20:38:18 CEST 2001
OEMCTRL for Linux: Version 2.2.0.0.0
Copyright (c) 1998, 2000, Oracle Corporation.  All rights reserved.
Starting the Oracle Management Server...VXA-3008 : Starting OMS Services,
Wait.

 [main][2001-9-13:20:38:21:491] Vxa - Initialization exception encountered!
oracle.sysman.vxn.VxnBootstrapException: nativeIsDomesticLib
        at
oracle.sysman.vxa.VxaAppServer.startServices(VxaAppServer.java:1436)
        at oracle.sysman.vxa.VxaAppServer.main(VxaAppServer.java:2547)

Error starting Oracle Management Server. nativeIsDomesticLib

<END LOG>

Anyone any suggestions what to look for?

Thanks
  Jos

2. Bad performance with triggers

3. Problems sybase - linux RH 7.1

4. Store Longint (32 bit) arrays in multiple rows

5. Fwd: Re: Shared memory for RH Linux 7.1

6. wierd rollback segment behavior - 8.0.5 on NT 4.0 Server

7. Shared memory for RH Linux 7.1

8. Fwd: Re: Shared memory for RH Linux 7.1

9. ORA-12545 Oracle Listener dieing afterapprox 60 seconds on linux RH 7.1

10. Trouble installing Oracle 8.1.7 in RH 7.1

11. 8i Install hangs before starting on RH 7.1

12. Oracle8i + RH 7.1