[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] Close port
That makes more sense. It would _have_ to be a kernel thread that choked.
So NFS is a highly likely culprit. NFS share of an iscsi or fiber channel
connection that drops and times out has been involved.
If NFS weren't so useful, I would never use it again.
On Jan 3, 2014 10:22 AM, "Derek Atkins" <derek at ihtfp.com> wrote:
> 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.
> > 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 Atkins 617-623-3745
> derek at ihtfp.com www.ihtfp.com
> Computer and Internet Security Consultant
> Ale mailing list
> Ale at ale.org
> See JOBS, ANNOUNCE and SCHOOLS lists at
-------------- next part --------------
An HTML attachment was scrubbed...