[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] Close port
- Subject: [ale] Close port
- From: derek at ihtfp.com (Derek Atkins)
- Date: Fri, 3 Jan 2014 10:20:39 -0500
- In-reply-to: <CAEo=5PxwR21nc6Zg4RyTstnXZh8rDkw-jioZC_GVxwaUOzUCOQ@mail.gmail.com>
- References: <CAEo=5Pw+iZFBMnC7uuiJghroUoN_G=nHz6NiF=SDGzoZDtVv6A@mail.gmail.com> <CAAt=rgC5bLb1GHsJRgNJazNvb3H45g7AjZwK0berYV6CHwmeTw@mail.gmail.com> <CAEo=5PxwR21nc6Zg4RyTstnXZh8rDkw-jioZC_GVxwaUOzUCOQ@mail.gmail.com>
Jim,
On Fri, January 3, 2014 10:03 am, Jim Kinney wrote:
> That's the "well behaved" process. I'm looking for a solution at the
> kernel
> control level that can alter the list of ports the kernel manages for the
> aberrant process that hangs with an open port and dies leaving it open. It
> feels like a kernel bug to have an open port with no process attached.
> Closing a port with the owning process still running would be a useful
> tool
> for testing that process' response to a system failure.
That would be a major kernel bug. When a process dies (not zombies, but
actually gets reaped) all open ports get closed. I've never seen a kernel
fail to reap that properly (although there are socket options to let it be
reused quickly, like SO_REUSEADDR).
More likely what happened here is that a *kernel thread* died and did not
get cleaned up properly. E.g. if NFS was running out of the kernel and a
mountpoint died in a mysterious way, it could be possible that it didn't
get reaped properly. Unlikely, but possible.
But yes, it is probably a kernel bug you are seeing.
-derek
--
Derek Atkins 617-623-3745
derek at ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant