hacl-cfg/udp: bind: Address already in use

[Joshua Laden]

Has anybody ever seen this error in their syslog? This started a couple of weeks ago, when I commented out the ftp, tftp, and telnet lines of the inetd.conf file. Later, that day, some users mentioned that some of their programs work on ftp. So I had to uncomment the lines. Now, ever since then, I keep getting the following errors, and I can't figure it out. Does anyone have any ideas on how to fix this?


Feb 20 08:32:59 dbqrtep2 inetd[3687]: hacl-cfg/udp: bind: Address already in use
Feb 20 08:32:59 dbqrtep2 inetd[3687]: hacl-cfg/udp: Service enabled
Feb 20 08:42:59 dbqrtep2 inetd[3687]: hacl-cfg/udp: bind: Address already in use
Feb 20 08:42:59 dbqrtep2 inetd[3687]: hacl-cfg/udp: Service enabled
Feb 20 08:52:59 dbqrtep2 inetd[3687]: hacl-cfg/udp: bind: Address already in use

[A. Clay Stephenson]

First of all, examine /etc/services to find the port number associated with hacl-cfg (5302 normally). You then can use netstat or lsof to find any processes already binding to that port number.

I suspect what really happended is that you either incorrectly modified inetd.conf so that there is a parsing error or you have more that one inetd running because you restarted inetd rather than sending a SIGHUP (kill -1) to the already running inetd. THe correct process is to issue an inetd -c command -- which does send a SIGHUP to the inetd process and triggers a reconfiguration of a running inetd.

[Joshua Laden]

Thanks for the input. But I use the inetd -c after making changes. I used only a # in front of the ftp, telnet, and tftp lines. Really no way to screw that up. After I saved the file, I used the inetd -c.

The only thing that is use the the 5302 is the localhost:
tcp 0 0 127.0.0.1.5302 127.0.0.1.61437 ESTABLISHED

Thanks,

Josh

[Kent Ostby]

A duplicate IP address can cause this issue in a SG cluster.

Check to make sure you don't have any dupe IPs.

Check to make sure your standby lans don't already have IP addresses assigned to them.

[Joshua Laden]

Thanks, Kent. I checked to make sure there weren't any duplicates. Everything seems fine on the IP front. I think it may be the port. See below:

dbqrtep2:/root#netstat -an |grep 5302
tcp 0 0 192.168.222.12.65302 192.168.222.12.10073 ESTABLISHED
tcp 0 0 127.0.0.1.61437 127.0.0.1.5302 ESTABLISHED
tcp 0 0 *.5302 *.* LISTEN
tcp 0 0 192.168.222.12.10073 192.168.222.12.65302 ESTABLISHED
tcp 0 0 127.0.0.1.5302 127.0.0.1.61437 ESTABLISHED
tcp 0 0 127.0.0.1.55966 127.0.0.1.5302 TIME_WAIT
tcp 0 0 127.0.0.1.55967 127.0.0.1.5302 TIME_WAIT
tcp 0 0 127.0.0.1.56010 127.0.0.1.5302 TIME_WAIT
tcp 0 0 127.0.0.1.56232 127.0.0.1.5302 TIME_WAIT
tcp 0 0 127.0.0.1.56098 127.0.0.1.5302 TIME_WAIT
tcp 0 0 127.0.0.1.56106 127.0.0.1.5302 TIME_WAIT
tcp 0 0 127.0.0.1.56088 127.0.0.1.5302 TIME_WAIT
tcp 0 0 127.0.0.1.56175 127.0.0.1.5302 TIME_WAIT
tcp 0 0 127.0.0.1.56191 127.0.0.1.5302 TIME_WAIT

[Procnus · Accepted solution]

What's the output from a:
lsof -iUDP:5302

The TCP port seems fine, the UDP port appears to be used by another process.

Cheers
Steven

[Joshua Laden]

Thanks for all of the help. Steven, you were right, it was the udp port that was in use. Everything is fine now.

Thanks again for the help

-Josh