tftpd

[I.Delic]

Hi,

Can somebody help me. I have some problem with load on mijn machine. tftpd take 98 % cpu.
I made an ftpusers file in /etc/ftpd with root in it.
Since i made this file i think this problem started.
i used ps -ef | grep tftpd en i get this
root 6259 917 241 Feb 26 ? 3238:26 tftpd /opt/ignite /var/opt/ignite

thank you

[I.Delic]

aditional information about my problem

We used one portscan program . I think sinds then i have this problem with high load .
How i can stop this deamon ? Is it possible and is it save to do this. This machine is live machine.
Can ik try inetd -c of something like this.

Thank you and i hope you can read my writing because my english lenguage is not very wel.


thank you

[Jeff Schussele]

Hi,

You can kill the process

kill 6259

Then in /etc/inetd.conf comment out the following line:

tftpd dgram udp wait root /usr/lbin/tftpd tftpd /opt/ignite /var/opt/ignite

Then run inetd -c to reread the new config & recycle inetd.

HTH,
Jeff

[I.Delic]

Jeff,

Thank you for your quick response. I have another question. Can i kill this proces without any problem. Do i need this proces for antoher application ?
I use ignite product for the disaster recovery


Thank you

Idriz

[Jeff Schussele · Accepted solution]

Hi Idriz,

If you're not actually creating or serving an Ignite image, then yes you can safely kill the process.
That should only be running when you are creating a make_net_recovery image or the server is doling one out to another host.

Rgds,
Jeff

[Jeff Schussele]

I should add that I believe your portscan did kick this off. When it hit your server with 67,68 or 69/UDP and since inetd.conf entry was not commented, your server dutifully fired off the command. It's probably just spinning & doing nothing but chewing up CPU cycles.

Rgds,
Jeff

[I.Delic]

thank you jeff

i just kill the process

he's gone

[rick jones]

a simple port scan should not produce a runaway process. if it does, then there is a bug in the code for that process that needs to be reported through official channels.

it might help if you could take a tusc trace of the tftpd process - something like:

tusc -v -o /tmp/tftp.tusc

where is the process ID of the tftp (or any other runaway) process.

killing it is all fine and good, but is only treating a symptom and does not preclude the problem from happening again in the future.

[David Barrington]

We have just had this happen too, and similarly we have found out that someone was using a port scanner.

What was the name of the port scanner in your case?