[ale] Close port

[Alex Carver]

For my case it's probably a very good guess that it was the fault of a
dead NFS connection.  One of my machines has a very small hard drive
(haven't gotten around to finding a bigger IDE drive for that particular
machine) so I loan it some space every so often via NFS from one of my
other machines (e.g. I map over /usr/src so I can compile but leave the
source code on the remote drive).  Once in a while I do lose the
connection (client suddenly disconnects and freezes due to an I/O fault)
but I have never rebooted the server since the last power outage
(yesterday was 221 days since the last reboot).

The NFS daemon was still running while I was investigating the strange
port.  But, when I shut down the daemon the port stayed put.  I actually
closed all connections to the machine, flipped over to the console and
shut down every running daemon (ssh, exim, nfs, portmap, udev, the
works) and the port stayed put showing up in netstat with no associated
process.

I wasn't too worried since no alarms were raised by integrit at any
point recently, the outer firewall is highly restrictive (the
misbehaving system has only one port available to the outside), and the
machine was not otherwise misbehaving.  But still it was really odd
hence the reason for asking. :)  So thanks go out to the ALE list. :)

On 1/3/2014 07:49, Jim Kinney wrote:
> 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
>>
> 
> 
> 
> _______________________________________________
> 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
>