I like the idea of goagain, but I'm surprised that so much code has to live in my main(). Can't we have a goagain.HttpListenAndserve()? This would be much more user friendly and solve the common case that one just wants to use go's builtin http server.

Is there a good reason it is not like this?

go get github.com/rcrowley/goagain on ubuntu results in github.com/rcrowley/goagain/goagain.go:191: function ends without a return statement for me.

this PR fixes this.

... parent stops listening and lingers for ten seconds handling slow requests before giving up, while the child picks up the listening socket immediately and continues serving requests.

The first time it runs.

goagain-e 9114 manuel 0u CHR 136,0 0t0 3 /dev/pts/0 goagain-e 9114 manuel 1u CHR 136,0 0t0 3 /dev/pts/0 goagain-e 9114 manuel 2u CHR 136,0 0t0 3 /dev/pts/0 goagain-e 9114 manuel 3u IPv4 678836 0t0 TCP 127.0.0.1:48879 (LISTEN) goagain-e 9114 manuel 4r FIFO 0,8 0t0 678837 pipe goagain-e 9114 manuel 5w FIFO 0,8 0t0 678837 pipe goagain-e 9114 manuel 6u 0000 0,9 0 6869 anon_inode goagain-e 9114 manuel 17r REG 0,3 0 410676 /proc/4972/auxv

Every subsequent time, it adds two more sockets.

goagain-e 9268 manuel 0u CHR 136,0 0t0 3 /dev/pts/0 goagain-e 9268 manuel 1u CHR 136,0 0t0 3 /dev/pts/0 goagain-e 9268 manuel 2u CHR 136,0 0t0 3 /dev/pts/0 goagain-e 9268 manuel 3u IPv4 678836 0t0 TCP 127.0.0.1:48879 (LISTEN) goagain-e 9268 manuel 4u IPv4 678836 0t0 TCP 127.0.0.1:48879 (LISTEN) goagain-e 9268 manuel 5r FIFO 0,8 0t0 688469 pipe goagain-e 9268 manuel 6w FIFO 0,8 0t0 688469 pipe goagain-e 9268 manuel 7u IPv4 678836 0t0 TCP 127.0.0.1:48879 (LISTEN) goagain-e 9268 manuel 8u 0000 0,9 0 6869 anon_inode goagain-e 9268 manuel 17r REG 0,3 0 410676 /proc/4972/auxv

Where are you reopening the socket?

Runtime go is the one that ships with Ubuntu 12.04.

Currently any project that includes goagain will be unbuildable on Windows due to syscall dependencies only present on some systems.

Would it be possible to create stubs that will be used for unsupported systems via build tags?

Of course there will not be any of the goagain functionality, but at least our developers on other platforms will be able to build projects using goagain.

PS. Thanks for an awesome project!

Hi,

Could you point me the direction how can I build the service which would support the "restart" operation?

The big goal of mine, is to develop an application which I would be able to restart using the command like service apache2 restart This case, when I have new binary uploaded, the new entity would be the updated application (am I right?)

As I understand the "goagain" is something I can use for this purpose. But I'm a bit lost about how should I use it.

I run the "single" example - I tried to kill it, to interrupt it, but neither operation has lead to the fact that the application was restarted.

1. How can I run the example app and see if it works?
2. Do you have any idea what I should research to be able to add graceful restart / stop and start to my application?

Thanks

Running the following httperf command... almost 4000 transactions are lost because it takes about a second to relaunch the app.

httperf --num-calls=4000 --port= 48879 --uri=/mock --num-conns=10

Looking closely at the code it's not possible to have a zero downtime.

(a) goagain shares open connection (b) there is no state migration (c) during the swap no new connections can be made and therefore potential transactions lost

/r

Unlike http://code.google.com/p/jra-go/source/browse/cmd/upgradable/main.go, the parent process doesn't actually stop listening or wait until it's done handling all requests, before it dies. This is because the child kills the parent and the parent exits unconditionally. This causes loss of requests.

I'm really confused why this doesn't work in OSX, the sub process always says that "dup: bad file descriptor" . But I have it working fine on linux. Any ideas of what to look at?

This tool does not handle SIGQUIT by default because it claims that Go "doesn't seem to like handling SIGQUIT". That may have been true in prior versions of Go, but in Go 1 SIGQUIT can be handled just like any other signal. Programs run under the "go run" tool aren't able to intercept SIGQUIT, but programs compiled to an executable and run work fine. Since a goal seems to be to mimic the behavior of Unicorn and nginx, I'd suggest that SIGQUIT can be used instead of SIGTERM.

Doing a go get github.com/rcrowley/goagain gives me:

C:\gd\src\github.com\ezbiz>go get github.com/rcrowley/goagain
# github.com/rcrowley/goagain
c:\gd\src\github.com\rcrowley\goagain\goagain.go:25: undefined: syscall.SIGUSR2
c:\gd\src\github.com\rcrowley\goagain\goagain.go:45: undefined: syscall.SIGUSR2
c:\gd\src\github.com\rcrowley\goagain\goagain.go:71: cannot use int(fd) (type int) as type syscall.Handle in function argument
c:\gd\src\github.com\rcrowley\goagain\goagain.go:92: undefined: syscall.Kill

This is go version go1.0.3 64-bit under Windows 7 64-bit. It's strange because syscall.Kill and syscall.SIGUSR2 are certainly "defined" under Go 1.0.3 as per the official pkg-docs..

Any idea what the issue could be here?

Every exported function in a program should have a doc comment. The first sentence should be a summary that starts with the name being declared. From effective go.

PR generated by CodeLingo. Install here to drive Continuous Higher Standards.

In Single strategy，setEnvs error in mac.

error message

panic: reflect: call of reflect.Value.Int on zero Value

goroutine 1 [running]:
reflect.Value.Int(...)
	/usr/local/go/src/reflect/value.go:961

solution

Replace with below code will solve this problems.

v := reflect.ValueOf(l).Elem().FieldByName("fd").Elem().FieldByName("pfd")
fd = uintptr(v.FieldByName("Sysfd").Int())

Drop resolving listener file descriptor by reflecting private struct fields. Instead we duplicate listener file descriptor, which handles closeOnExec syscalls.

The current implementation uses reflect package, and is prone to break (actually as of go 1.9 it WILL break, because the netFD struct fields have been moved around and sysfd field does not exist anymore, and is reachable instead by pfd poll.FD field).

Fixes a rogue close() that happens whenever the GC next runs after Listen(). NewFile() takes responsibility for the fd it is passed but Listen() then proceeds to manually syscall.Close() the fd anyway. So when the file object gets finalized it is closed a second time, either causing an EBADF or closing some other random file.

I agree with #2 and #3 that logging should not forced upon users of this library. But I also agree with @rcrowley that the logging is useful and needed. This PR doesn't change the default logging functionality but adds a Logger var on the package that can be set to override where log messages go.

This can be useful for applications that already have a logger setup and want the goagain logs to go to the same place. You just set

myLogger := log.New(myWriter, "err: ", log.LstdFlags)
goagain.Logger = myLogger

Or if you wanted to disable logging altogether, you can set

goagain.Logger = nil