Closed andig closed 11 months ago
Run a go application in Docker on Synology NAS/amd64.
Can you describe what that does in a way that we can reproduce without access to a Synology device?
(Presumably this is a variant of linux/amd64
?)
Specifically:
stdout
connected to? (Is it a pipe? A regular file? Something else?)SIGSTOP
, or something else?If stdout
is connected to a pipe, and some other process is holding that pipe open but not reading from it, then the fact that the write
system call blocks is as described by POSIX (https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html):
If the
O_NONBLOCK
flag is clear, a write request may cause the thread to block ….
And the Go runtime leaves the O_NONBLOCK
flag for os.Stdout
set to whatever it was already set to when the program was started.
I'm no Unix expert but it seems as if it would be helpful if the write eventually was able to time out. If not it would be great if I could work around this somehow, e.g. setting a write deadline or similar?
Timed out in state WaitingForInfo. Closing.
(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env
)?go env
OutputNote
go env
output is not from Docker host.What did you do?
What did you expect to see?
Application continues running and serving requests.
What did you see instead?
Application gets stuck. I've noticed this behavior with various Docker applications, usually leading to the docker host no longer serving requests either while the applications themselves are still functional.
This issue however is not about the Docker process, but about the Go runtime's behaviour:
pprof
OutputAnalysis
Afaikt all interesting go routines are stuck on either
syscall
orsemacquire
, all coming fromos.(*File).Write
called by the same routine (util.(*Redactor).Write
) which writes toos.Stdout
:I think whats happening here is that something goes wrong with
os.Stdout
which eventually leads tosyscall.write
getting stuck.I'm no Unix expert but it seems as if it would be helpful if the write eventually was able to time out. If not it would be great if I could work around this somehow, e.g. setting a write deadline or similar?