Thanks for your reply. It definitely only happens after opening a connection to an external server. And if I run tcpdrop on the connections before shutting the jail down, it works every time. Though the connection to my browser (the program hosts a web application) doesn't cause a problem, which makes me think it's only connections where the in-jail application is the client. Also, I tried using a short Python script that just opened a tcp connection to another server and tried to shutdown the jail. It waited for a while (which it didn't in the Go case), but still failed with "device busy".
I did manage to put together a script using tcpdrop that could pick out only the right connections to drop, but my code reviewer doesn't like the solution; he wants to solve the problem from within Go rather than hack our way around it. I have also tried manually killing the process before shutting down the jail. Regardless of SIGTERM or SIGKILL, the program exits immediately and the connections are left in TIME_WAIT. On Sunday, February 17, 2019 at 9:35:44 PM UTC-5, Kurtis Rader wrote: > > On Sun, Feb 17, 2019 at 5:11 PM <rlwes...@gmail.com <javascript:>> wrote: > >> I have an application running in a FreeBSD jail that opens TCP >> connections to other servers. When I try to shutdown the jail shortly after >> opening a connection, it fails to unmount the filesystem with "device >> busy". I've tried all manner of sysctl options and >> server.SetKeepalivesEnabled(false) and similar functions, but nothing has >> any effect. I think it might be because there are a lot of places in the >> code this can happen and some of the connections might be getting opened by >> code in other repos I'm importing. Is there an easy way to just close all >> open TCP connections? >> > > What makes you think open TCP connections are the problem? I've never seen > a case where a process can't be killed thus closing all open file > descriptors including those open on TCP connections. I suspect you are > barking up the wrong tree. You've got a process in an uninterruptible > state. That process may or may not be your golang program. The first thing > to do is try to manually kill that process before shutting down the > container it is running in. If you can't kill it you need to investigate > what state the process is in which should explain why it can't be killed > and the jail container successfully shutdown. > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
