[ale] Close port

[Jim Kinney]

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:

> 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
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140103/6e6eb7a6/attachment-0001.html>