net/http: Hijack deadlock if system clock is 1970

[eidmanna]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.8 windows/amd64
with crosscompile GOOS: "linux", GOARCH: "arm"

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=E:\gopath
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
set PKG_CONFIG=pkg-config
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2

with crosscompile for
GOOS: "linux",
GOARCH: "arm"

--> for raspberry pi with no internal clock

What did you do?

Start the programm and call --> :8080/test

package main

import (
"log"
"net/http"

_ "net/http/pprof"
)

func main() {
http.HandleFunc("/test", testHandler)
panic(http.ListenAndServe(":8080", nil))
}

func testHandler(w http.ResponseWriter, r *http.Request) {
h := w.(http.Hijacker)
log.Println("calling hijack")
c, _, err := h.Hijack()
log.Println("hijack returned err=", err)
c.Close()
}

What did you expect to see?

No deadlock

What did you see instead?

Deadlock in call to
c, _, err := h.Hijack()

The reason for this deadlock is, that the clock is set to
1970/01/01
With newer date eg 2017/01/01 no deadlock.

For details, discussion and heapdump see:
gorilla/websocket#232

@garyburd agreed, that this is probably an net/http issue

[bradfitz]

Yes, the net and net/http packages implement some connection timeout logic by changing the timeout to times way in the past. But apparently on your machine aLongTimeAgo is actually in the future and not in the past.

We could move aLongTimeAgo even earlier, perhaps to 1 second past the start of unix time.

But does your clock at least advance ever, even though it boots at 1970-01-01?

Which Raspberry Pi is this?

[eidmanna]

I have a Raspberry Pi 3 Model B.

The time during my test was:
1970/01/01 01:13:59 (output of time by log.Println)

1 hour 13 min after boot.

[bradfitz]

I see. And you don't want to use ntp to fix the clock?

This is an HTTP server, so by definition it at least has some network available. Or maybe it's just localhost or local LAN?

And you're fine with the Server's "Date" response header being wrong? And Last-Modified and If-Modified-Since and such not working quite right?

I guess the question is how much we make an effort to do the right thing for busted clocks. I suppose Raspberry Pis are common, so we should make some effort.

[eidmanna]

Now it is easy for me to fix it.

But it was not easy to figure out, that an old timestamp was the reason for a broken websocket.

My raspberry pi has no internet connection, only local lan. Without any changes I have this old timestamp automatically. Raspberry pi has no internal battery clock.

For my IoT project I do not need a correct time.

BTW: In the standard raspberry pi image ntp is installed and setup by default.

[bradfitz]

@rsc, cool to adjust aLongTimeAgo to Unix(1, 0)?

[rsc]

@bradfitz OK

[gopherbot]

CL https://golang.org/cl/38785 mentions this issue.

[gopherbot]

CL https://golang.org/cl/38786 mentions this issue.