Re: How to delete unix socket entries

From: Terry Lambert (tlambert2_at_mindspring.com)
Date: 06/25/03

  • Next message: Paul Robinson: "Re: How to delete unix socket entries"
    Date: Wed, 25 Jun 2003 03:21:11 -0700
    To: Varshavchick Alexander <alex@metrocom.ru>
    
    

    Varshavchick Alexander wrote:
    > Terry, you're right that all this happened because of the server
    > application core dumped while in the process of sending/receiving data,
    > and that application is fixed so there are no new zombi sockets, but what
    > can I do now with the ones which already exist? How can I delete them now?

    If it's fixed: reboot.

    If it's not fixed, add this to your /etc/rc.local:

            sysctl net.inet.tcp.always_keepalive=0

    ...and reboot.

    Nothing short of rebooting is going to undo the deadlock, unless
    you have the kernel debugger compiled into your kernel, and are
    willing to grovel around in data structures to find the root cause
    of your problem.

    There is no such thing as a "zombie socket", there are only sockets
    which are in TIME_WAIT, FIN_WAIT, FIN_WAIT_2, etc., states. These
    tend to persist for 2MSL (about 5 minutes) after the process has
    exited.

    That you are having this problem is indicative of the other end of
    the socket connection still being alive somewhere, and/or a real
    bug that was triggered by the default being to set "keepalive" on
    the sockets, even though they are UNIX domain sockets. You could
    probably fix this by overriding the "keepalive" setting on the
    created sockets in the kernel function "socketpair".

    Without a reproducible test case, I can't provide you a kernel patch
    to fix the problem for you in the future. My advice is to turn off
    the keepalive; I expect it will help.

    -- Terry
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  • Next message: Paul Robinson: "Re: How to delete unix socket entries"

    Relevant Pages

    • Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
      ... OpenSSH works with network and unix sockets in parallel, ... kernel services, and the continued well being of the kernel, not ... And even if you will cover all kernel-only network allocations, ... Feel free to implement any receiving policy inside _separated_ allocator ...
      (Linux-Kernel)
    • SOLVED Re: Solaris 2.8 & 2.9 kernel eating all my memory?
      ... The problem ended up being an app issue that was framing the kernel. ... and repeat (keeping the older sockets open). ... I think we will end up rewriting the load generation program to use ... > simultaneous connections without any problems. ...
      (comp.unix.solaris)
    • Re: [RFC] Revised CKRM release
      ... >>implemented as kernel modules, ... they don't take resources away from the group serving a "gold" customer. ... rates for groups of listening sockets formed using source ip/port. ... independent - the resource controllers (which are/will be patches over ...
      (Linux-Kernel)
    • Re: sending messages, user process <--> kernel module
      ... >> about implementing something similar to unix routing socket, ... > buffers kernel log output for syslogd to pick up asynchronously. ... > userspace cache managers. ... including UNIX domain sockets and TCP/IP sockets. ...
      (freebsd-hackers)
    • Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
      ... It does not matter how condition when not every user can get memory is ... OpenSSH works with network and unix sockets in parallel, ... OpenSSH or any other user-space program will never ever have the problem ... kernel services, and the continued well being of the kernel, not ...
      (Linux-Kernel)