openssh bugs - Jul 2007 - [Bug 1329] New: stale control sockets prevent connection.

http://bugzilla.mindrot.org/show_bug.cgi?id=1329

           Summary: stale control sockets prevent connection.
           Product: Portable OpenSSH
           Version: 4.6p1
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ssh
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: dwmw2 at infradead.org


Created an attachment (id=1318)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1318)
clean up stale control sockets

If there's a stale socket lying around, we should remove it rather than
just failing to connect to it and then aborting.


-- 
Configure bugmail: http://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org




--- Comment #1 from Damien Miller <djm at mindrot.org>  2008-06-12
16:51:31 ---
what about cases where the mux server has exceeded its connection
backlog? wouldn't you end up zapping a live mux socket there?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329





--- Comment #2 from Damien Miller <djm at mindrot.org>  2008-06-12
16:55:07 ---
Created an attachment (id=1513)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1513)
fall back from mux client to TCP connection on error

I think this approach is safer: fall back to creating a new TCP
connection after errors in the mux client path.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1208




-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1349




-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329





--- Comment #3 from Damien Miller <djm at mindrot.org>  2008-06-12
16:57:28 ---
Created an attachment (id=1514)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1514)
fall back from mux client to TCP connection on error

I think this approach is safer: fall back to creating a new TCP
connection after errors in the mux client path.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.6p1                       |5.0p1
         OS/Version|Linux                       |All
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #4 from Damien Miller <djm at mindrot.org>  2008-06-13
10:17:49 ---
patch applied; will be in openssh-5.1

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED




--- Comment #5 from Damien Miller <djm at mindrot.org>  2008-07-22
12:19:01 ---
Mass update RESOLVED->CLOSED after release of openssh-5.1

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329

--- Comment #6 from David Woodhouse <dwmw2 at infradead.org>  ---
(In reply to comment #1)
> what about cases where the mux server has exceeded its connection
> backlog? wouldn't you end up zapping a live mux socket there?
I don't think so. In that case, you'll get a fairly long (perhaps
infinite?) timeout on connect() followed by -EAGAIN.

You could _only_ get -ECONNREFUSED if there really isn't anything
listening, I believe.

(In reply to comment #3)
> I think this approach is safer: fall back to creating a new TCP
> connection after errors in the mux client path.
The problem with this approach is that when there are stale sockets
lying around, it looks nothing will ever clean them up. So with
'ControlMaster Auto' you will keep falling back to TCP connections and
not using the mux socket (and not creating a new mux socket) for ever.

I much prefer the option of deleting the offending socket.

On the other hand, perhaps we just don't want sockets to appear in the
file system at all -- perhaps we should allow the user to use
'abstract' socket addresses.... see bug #1775.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329

David Woodhouse <dwmw2 at infradead.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|stale control sockets       |stale control sockets
                   |prevent connection.         |prevent connection
                   |                            |multiplexing.
             Status|CLOSED                      |REOPENED
         Resolution|FIXED                       |

--- Comment #7 from David Woodhouse <dwmw2 at infradead.org> 2011-03-10
02:33:59 EST ---
This *used* to work with my old patches; the stale control socket would
be removed.

 $ ssh macbook
Control socket connect(/home/dwmw2/.ssh/sockets/macbook-22-dwmw2):
Connection refused
ControlSocket /home/dwmw2/.ssh/sockets/macbook-22-dwmw2 already exists,
disabling multiplexing
[dwmw2 at macbook ~]$ logout
Connection to macbook closed.
 $ ssh macbook
Control socket connect(/home/dwmw2/.ssh/sockets/macbook-22-dwmw2):
Connection refused
ControlSocket /home/dwmw2/.ssh/sockets/macbook-22-dwmw2 already exists,
disabling multiplexing
[dwmw2 at macbook ~]$

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329

David Woodhouse <dwmw2 at infradead.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1318|0                           |1
        is obsolete|                            |
   Attachment #1513|0                           |1
        is obsolete|                            |
   Attachment #1514|0                           |1
        is obsolete|                            |

--- Comment #8 from David Woodhouse <dwmw2 at infradead.org> 2011-05-20
22:22:58 EST ---
Created attachment 2050
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2050
Patch to unlink stale socket, against 5.6p1

This patch fixes the problem.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329

David Woodhouse <dwmw2 at infradead.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2050|0                           |1
        is obsolete|                            |

--- Comment #9 from David Woodhouse <dwmw2 at infradead.org> 2011-05-23
19:46:01 EST ---
Created attachment 2051
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2051
Remove stale socked only if ControlMaster=auto

This version is modified to further address the fear in comment #1 ?
even though I don't think it's valid, as I explained in comment #6.

It will now *only* remove the non-responsive socket if a replacement
socket is going to be automatically recreated (i.e. ControlMaster set
to auto or autoask).

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Damien Miller <djm at mindrot.org> 2011-06-03
12:20:33 EST ---
IIRC this was fixed in 5.8. We have this code now:
> if (errno == ECONNREFUSED &&
>     options.control_master != SSHCTL_MASTER_NO) {
>         debug("Stale control socket %.100s, unlinking", path);
>         unlink(path);
> }
-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #11 from Damien Miller <djm at mindrot.org> 2011-09-06
15:33:00 EST ---
close resolved bugs now that openssh-5.9 has been released

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1329

Jan F. Chadima <jfch at jagda.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jfch at jagda.eu

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.