On 06/04/2012 04:46 PM, Raghavendra Bhat wrote: > > Glusterfs client starts binding from port number 1023 and if any port > is not available, then tries to bind to the lower port. (i.e. suppose > 1023 is not available because some other process is already using it, > then it decrements the port to 1022 and tries to bind.) So in this > case it has tried all the ports starting 1023 and found that those > ports are not free (used by other processes) and found that port 80 > is free and just did bind on it. No, that's impossible that so many ports, from 1023 down to 80, would be used. OK, some more background on this. 1) actually it's not gluster listening; it's a connection from remote gluster to this gluster, on port 80, but it prevents the webserver from starting 2) reproducible when using "replace-brick" (I'm replacing a number of bricks, and could reproduce it with all of them so far): gluster volume replace-brick sites ca4-int:/data/glusterfs ca3-int:/data/12 start 3) when "replace-brick" is running, nginx accessing gluster "hangs" (its processes are in D state, waiting for IO) 4) the only cure is killing nginx and glusterfs 5) when doing mount -a (to mount gluster) and starting nginx after that, sometimes nginx wouldn't start, as there is some glusterfs local process with an open connection to port 80 (locally) -- Tomasz Chmielewski http://www.ptaveler.com
