ReadResponse(StatusReady) in DialTimeout hang

[alexzyp]

https://github.com/jlaffaye/ftp/blob/master/ftp.go#L88

Hi,

my program have multiple connections to LIST different directories per second and the ftp server is Serv-U v5.0. after a while, some connections hang. netstat command shows that the tcp state is ESTABLISHED. run ftp.DialTimeout with some duration does not help.

func ftpListDirectory(path string) ([]*ftp.Entry, error) {
	conn, err := ftp.DialTimeout(cfg.FtpSrvAddr, 5*time.Second)
	if err != nil {
		return nil, err
	}
	conn.DisableEPSV = true
	defer conn.Quit()

	if err = conn.Login(cfg.FtpSrvUser, cfg.FtpSrvPwd); err != nil {
		return nil, err
	}

	return conn.List(path)
}

[kunhou]

Same question

[corny]

Did you already try tcpdump do inspect the connections? You could also use http://golang.org/pkg/net/http/pprof/ to get a stacktrace of all go routines, see also: https://stackoverflow.com/a/19145992

[alexzyp]

@corny Thanks.

This is the stack dump of blocking goroutine (go version 1.8.3, 32-bit)

goroutine 10 [IO wait, 6 minutes]:
net.runtime_pollWait(0x30fe89d0, 0x72, 0x101)
	C:/Go/src/runtime/netpoll.go:164 +0x4b
net.(*pollDesc).wait(0x111f1d08, 0x72, 0x10f17c28, 0x0)
	C:/Go/src/net/fd_poll_runtime.go:75 +0x2b
net.(*ioSrv).ExecIO(0x10f286e8, 0x111f1c58, 0x7282d1, 0x7, 0x7405ec, 0x8b5570, 0x0, 0x12)
	C:/Go/src/net/fd_windows.go:196 +0xb9
net.(*netFD).Read(0x111f1c20, 0x112b4000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
	C:/Go/src/net/fd_windows.go:452 +0xec
net.(*conn).Read(0x110436c0, 0x112b4000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
	C:/Go/src/net/net.go:181 +0x56
bufio.(*Reader).fill(0x11187710)
	C:/Go/src/bufio/bufio.go:97 +0xd5
bufio.(*Reader).ReadSlice(0x11187710, 0x1128360a, 0xe, 0xe, 0x43c93b, 0x1128368b, 0x11283673)
	C:/Go/src/bufio/bufio.go:338 +0x92
bufio.(*Reader).ReadLine(0x11187710, 0x5, 0x11283680, 0x1c, 0xfde29ac, 0x0, 0x20)
	C:/Go/src/bufio/bufio.go:367 +0x2a
net/textproto.(*Reader).readLineSlice(0x112dacd0, 0x110d6520, 0x20, 0x3fffff, 0x0, 0x0)
	C:/Go/src/net/textproto/reader.go:55 +0x45
net/textproto.(*Reader).ReadLine(0x112dacd0, 0x1, 0xfde29ab, 0x40d0e6, 0x110d6540)
	C:/Go/src/net/textproto/reader.go:36 +0x21
net/textproto.(*Reader).readCodeLine(0x112dacd0, 0xdc, 0x110d6540, 0x31212ccc, 0x0, 0x110d6520, 0x10fbe280, 0x30f004a0)
	C:/Go/src/net/textproto/reader.go:177 +0x25
net/textproto.(*Reader).ReadResponse(0x112dacd0, 0xdc, 0x0, 0x110d6520, 0x0, 0x110d6520, 0x88b840)
	C:/Go/src/net/textproto/reader.go:255 +0x2d
github.com/jlaffaye/ftp.DialTimeout(0x72f4f6, 0x13, 0x2a05f200, 0x1, 0x2, 0x435a3f, 0x10f17eec)
	D:/zyp/work/go/src/github.com/jlaffaye/ftp/ftp.go:88 +0x2e8
main.ftpListDirectory(0x10fc8068, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0)
	d:/zyp/work/go/src/cn02020.com/zyp/xjftp/xjdownloader/xjdownloader.go:148 +0x67
main.outWaiter.start(0x10fd83a0, 0x725a36, 0x3, 0x7258c8, 0x3, 0x10f944e0, 0x1c, 0x10f94500, 0x1c)
	d:/zyp/work/go/src/cn02020.com/zyp/xjftp/xjdownloader/xjdownloader.go:95 +0x107
created by main.main
	d:/zyp/work/go/src/cn02020.com/zyp/xjftp/xjdownloader/xjdownloader.go:234 +0x64a

and the netstat command output on windows server 2003 machine

C:\XML\XML_File_Temp\xjftp>netstat -ano | findstr 2221
  TCP    10.43.220.108:2535     121.33.205.117:2221    ESTABLISHED     2684

I have tried to add these lines.

d:\zyp\work\go\src\github.com\jlaffaye\ftp>git diff
diff --git a/ftp.go b/ftp.go
index 831fb98..d956a53 100644
--- a/ftp.go
+++ b/ftp.go
@@ -71,6 +71,11 @@ func DialTimeout(addr string, timeout time.Duration) (*ServerConn, error) {
        if err != nil {
                return nil, err
        }
+       err = tconn.SetDeadline(time.Now().Add(timeout))
+       if err != nil {
+               tconn.Close()
+               return nil, err
+       }

        // Use the resolved IP address in case addr contains a domain name
        // If we use the domain name, we might not resolve to the same IP.

so ReadResponse(StatusReady) in DialTimeout would failed with i/o timeout. But i still found one connection blocked there with CLOSE_WAIT state after running several days.

[gpfei]

Running into the same problem. Has it been resolved?

[ninhdhx]

Face the same issue, any update on this ?

[jlaffaye]

Do you have code to reproduce the issue ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.