Error Tcp Bind Error Address Already In Use
Contents |
Post #1 of 4 (2993 views) Permalink ERROR: TCP: bind() error: Address already in use Hi ! I´ve noticed that
Clamav Error Tcp Bind Error Address Already In Use
my clamAV was not working . I tried a restart but nothing creating server tcp listening socket 6379 bind address already in use happened. This is my log: +++ Started at Sat Oct 23 19:13:21 2010 clamd daemon 0.96.2 (OS: linux-gnu, bind address already in use linux ARCH: i386, CPU: i686) Running as user vscan (UID 65, GID 105) Log file size limited to 2097152 bytes. Reading databases from /var/lib/clamav Not loading PUA signatures. Loaded 847836 signatures. ERROR:
Error Binding Socket Address Already In Use
TCP: bind() error: Address already in use Took a look at the processess: ps ax | grep clam 2628 ? Ss 0:00 /usr/bin/freshclam -d 2643 ? Ssl 0:00 /usr/sbin/clamav-milter Any hint? Thanks! _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml jimlinux at commspeed Oct24,2010,11:52AM Post #2 of 4 (2934 views) Permalink Re: ERROR: TCP: bind() error: Address already in use [In
Address Already In Use Python
reply to] On 10/23/2010 03:23 PM, augustocasagrande [at] gmail wrote: > Hi ! I´ve noticed that my clamAV was not working . > I tried a restart but nothing happened. > This is my log: > > +++ Started at Sat Oct 23 19:13:21 2010 > clamd daemon 0.96.2 (OS: linux-gnu, ARCH: i386, CPU: i686) > Running as user vscan (UID 65, GID 105) > Log file size limited to 2097152 bytes. > Reading databases from /var/lib/clamav > Not loading PUA signatures. > Loaded 847836 signatures. > ERROR: TCP: bind() error: Address already in use > > Took a look at the processess: > ps ax | grep clam > 2628 ? Ss 0:00 /usr/bin/freshclam -d > 2643 ? Ssl 0:00 /usr/sbin/clamav-milter > > A couple of things, is the socket there even though process died? Check your config file to see where the socket is located. What address is reserved for clamav and what is listening on that address. You can use netstat -l to determine what ports are being listened for. Jim _______________________________________________ Help us build a comprehensive ClamAV guide: visit
and both ends must ACK (acknowledge) each other's FIN packets. The FIN packets are initiated by the application performing a close(), a shutdown(), or an exit(). The ACKs are handled by the kernel after the close() has completed. Because of this, bind failed address already in use iperf it is possible for the process to complete before the kernel has released the associated network
So_reuseaddr Example In C
resource, and this port cannot be bound to another process until the kernel has decided that it is done. Figure 1 Figure 1 shows all bind: address already in use mac of the possible states that can occur during a normal closure, depending on the order in which things happen. Note that if you initiate closure, there is a TIME_WAIT state that is absent from the other side. This TIME_WAIT is necessary http://www.gossamer-threads.com/lists/clamav/users/50499 in case the ACK you sent wasn't received, or in case spurious packets show up for other reasons. I'm really not sure why this state isn't necessary on the other side, when the remote end initiates closure, but this is definitely the case. TIME_WAIT is the state that typically ties up the port for several minutes after the process has completed. The length of the associated timeout varies on different operating systems, and may be dynamic on some operating systems, however typical http://hea-www.harvard.edu/~fine/Tech/addrinuse.html values are in the range of one to four minutes. If both ends send a FIN before either end receives it, both ends will have to go through TIME_WAIT. Normal Closure of Listen Sockets A socket which is listening for connections can be closed immediately if there are no connections pending, and the state proceeds directly to CLOSED. If connections are pending however, FIN_WAIT_1 is entered, and a TIME_WAIT is inevitable. Note that it is impossible to completely guarantee a clean closure here. While you can check the connections using a select() call before closure, a tiny but real possibility exists that a connection could arrive after the select() but before the close(). Abnormal Closure If the remote application dies unexpectedly while the connection is established, the local end will have to initiate closure. In this case TIME_WAIT is unavoidable. If the remote end disappears due to a network failure, or the remote machine reboots (both are rare), the local port will be tied up until each state times out. Worse, some older operating systems do not implement a timeout for FIN_WAIT_2, and it is possible to get stuck there forever, in which case restarting your server could require a reboot. If the local application dies while a connection is active, the port will be tied up in TIME_WAIT. This is also true if the application dies while a connection is pending. Strategies for Avoidance SO_REUSEADDR You can use setsockopt() to set the S
Forums » Tutorial and setups » TVH - unstable version - [ ERROR] tcp: bind: *: Address already in use Added by Joerg B almost 2 years ago Hi, since a few versions, I can't start the unstable version of TVH anymore, the stable version works without any problems.When I https://tvheadend.org/boards/4/topics/14107 want to run TVH I got this error message:2014-11-20 10:57:13.665 [ ERROR] tcp: bind: *: Address already in use I started some investigation and the main difference for me is the port listening. This is my netstat with the unstable version:Proto Recv-Q Send-Q https://forum.golangbridge.org/t/bind-address-already-in-use-even-after-listener-closed/1510 Local Address Foreign Address State User Inode PID/Program nametcp 0 0 0.0.0.0:9981 0.0.0.0:* LISTEN 0 91276 22879/tvheadend tcp 0 0 0.0.0.0:9982 0.0.0.0:* LISTEN 0 91279 22879/tvheadend As soon as I use the unstable version, the user is set to 0, which seems to address already be wrong. While in the stable version it's user 116 and all is fine. the entry in etc/passwd is always the same:hts:x:116:125::/home/hts:/bin/bash Any ideas? The stable version is not an option, as I would like to use the SAT>IP function. Edit: Almost forgot. I'm using Xubuntu 14.04. Joerg Replies (4) RE: TVH - unstable version - [ ERROR] tcp: bind: *: Address already in use - Added by Prof Yaffle almost 2 years ago How are you starting tvh? Or what does ps -eaf | grep tvh address already in say about the process? EDIT The tcp: bind: *: Address already in use bit suggests that tvh is already running, perhaps... RE: TVH - unstable version - [ ERROR] tcp: bind: *: Address already in use - Added by Joerg B almost 2 years ago It seems TVH is already running, but perhaps not stable since the PID is permanently changing. ps -eaf | grep tvh:UID PID PPID C STIME TTY TIME CMDhts 11982 1 0 11:25 ? 00:00:00 tvheadend -f -u hts -g videoqa 12003 31168 0 11:25 pts/1 00:00:00 grep --color=auto tvh after a few seconds:UID PID PPID C STIME TTY TIME CMDhts 12005 1 43 11:25 ? 00:00:00 tvheadend -f -u hts -g videoqa 12026 31168 0 11:25 pts/1 00:00:00 grep --color=auto tvh RE: TVH - unstable version - [ ERROR] tcp: bind: *: Address already in use - Added by Prof Yaffle almost 2 years ago Sounds like you've got an installed version that, as you say, is crashing and respawning. Check syslog, you'll see the crash and startup messages there. Xubuntu Trusty is a perfectly good base, so I doubt that's relevant. Check your tvh version, see if you can work out why/where it's crashing, try a later version; after that, you're into gdb and backtracing to see why/where it's dying. You also need to figure out why you have two versions - I presume you have one installed as a service (from PPA or dpkg -i *.deb) and one that's starting independently (e.g. from build.linux?). If it's not that then you
// ln is listening on :8080 err = ln.Close() // succeeds, no error if err != nil { log.Fatal(err) } ln2, err := net.Listen("tcp", ":8080") if err != nil { log.Fatal(err) // bind: address already in use } I was wondering if SO_REUSEADDR had something to do with this, but as far as I know, that is already being used under the hood in the Go standard library when creating a new tcp listener. Any ideas how I can re-bind to that address without delay? jdh (Joe Henke) 2015-11-14 18:40:19 UTC #2 Hey Matt, I tried to reproduce this and did not on my mac but did on the go playground. Where did this happen for you? Interestingly, both on my mac and on the go playground, if you use -addr="" or change to defaultAddr to "" in the source (which I think just means it will bind to any open port, yeah?) it will never rebind to the same port, and in fact will bind to the previous attempt's port + 1. Not sure if this is significant; I don't know precisely what binding to "" is specced to do. Joe matt (Matt Holt) 2015-11-14 19:09:42 UTC #3 Thanks for trying to reproduce it - next time I'll try to provide a full code sample I'm experiencing the Go playground's behavior on my Mac. But when I ran your test program on my Mac, it passed. I will look into this further in my own program. Meanwhile, I am intensely curious as to why the test fails on the Go playground... matt (Matt Holt) 2015-11-14 19:57:23 UTC #4 Okay, I've narrowed it down a little bit. This only happens for me when my program has restarted itself using exec.Command(os.Args[0], ...) and, in that command, it sets ExtraFiles to a list of file descriptors for listeners. (Similar to this method: http://grisha.org/blog/2014/06/03/graceful-restart-in-golang/) This lets the child process (itself) use the existing listeners without downtime. In the "restarted" process, then: I close the listeners, immediately create new ones on the same addresses again, and it fails with "address already in use". But if I pause 5 seconds after closing the listener (before creating the new listener), it succeeds. The original process where the listeners were created don't have this problem. In other words, if I don't "restart" the process, I can close and create the listeners immediately, like @jdh's program does. But if I do that same thing in a restart, it doesn't work. Here's a program that reproduces what I'm describing: gist.github.com https://gist.github.com/mholt/54caa1190cc6b14a43b1 socket_reuse.go package main import ( "flag" "log" "net" "os" "os/exec" ) This file has been truncated. show original The erroring line is line 44. Are you seeing the same thing? Any ide