Subject: Bug#3541: rlogin blocks on ECONNREFUSED!

From: Richard Kettlewell <[email-masked]>
Date: Sat, 6 Jul 96 23:49:42 +0100 (BST)

Package: netstd
Version: 2.05-1

If you try to rlogin to a system not listening for that service,
instead of producing an error message the program appears to hang.
rsh and rcp display similar behaviour.

As you can see below rlogin retries the connection every 2 seconds,
which IMHO is not a very sensible thing to do.  I'm currently using
kernel 2.0.2 and libc 5.2.18.

richard@sfere:richard$ really strace rlogin localhost
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 4294967295, 0) = 0x40006000

[.........much stuff omitted........]

open("/etc/hosts", O_RDONLY)            = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=671, ...}) = 0
read(3, "127.0.0.1\t\t\t\t\t\t\tlocalhost"..., 4096) = 671
read(3, "", 4096)                       = 0
close(3)                                = 0
sigprocmask(SIG_BLOCK, [IO], [USR1 IO]) = 0
ipc_subcall(0x2, 0x1, 0, 0x40047dd0)    = 3
ipc_subcall(0x3, 0xbffff838, 0x10, 0x40047e27) = 0
fcntl(3, F_SETOWN, 588)                 = 0
ipc_subcall(0x3, 0xbffff8ac, 0x10, 0x400478d1) = -1 ERRNO_111 (Connection refused)
close(3)                                = 0
sigprocmask(SIG_BLOCK, [ALRM], [USR1 IO]) = 0
sigaction(SIGALRM, {0x40062170, [], 0}, {SIG_DFL}) = 0
time(NULL)                              = 836692738
alarm(1)                                = 0
sigsuspend([USR1 IO] <unfinished ...>
--- SIGALRM (Alarm clock) ---
<... sigsuspend resumed> )              = -1 ERRNO_4 (Interrupted system call)
sigreturn()                             = ? (mask now [USR1 ALRM IO])
time(NULL)                              = 836692739
sigaction(SIGALRM, {SIG_DFL}, NULL)     = 0
alarm(0)                                = 0
sigprocmask(SIG_SETMASK, [USR1 IO], NULL) = 0
ipc_subcall(0x2, 0x1, 0, 0x40047dd0)    = 3
ipc_subcall(0x3, 0xbffff838, 0x10, 0x40047e27) = 0
fcntl(3, F_SETOWN, 588)                 = 0
ipc_subcall(0x3, 0xbffff8ac, 0x10, 0x400478d1) = -1 ERRNO_111 (Connection refused)
close(3)                                = 0
sigprocmask(SIG_BLOCK, [ALRM], [USR1 IO]) = 0
sigaction(SIGALRM, {0x40062170, [], 0}, {SIG_DFL}) = 0
time(NULL)                              = 836692739
alarm(2)                                = 0
sigsuspend([USR1 IO] <unfinished ...>
--- SIGALRM (Alarm clock) ---
<... sigsuspend resumed> )              = -1 ERRNO_4 (Interrupted system call)
sigreturn()                             = ? (mask now [USR1 ALRM IO])
time(NULL)                              = 836692741
sigaction(SIGALRM, {SIG_DFL}, NULL)     = 0
alarm(0)                                = 0
sigprocmask(SIG_SETMASK, [USR1 IO], NULL) = 0
ipc_subcall(0x2, 0x1, 0, 0x40047dd0)    = 3
ipc_subcall(0x3, 0xbffff838, 0x10, 0x40047e27) = 0
fcntl(3, F_SETOWN, 588)                 = 0
ipc_subcall(0x3, 0xbffff8ac, 0x10, 0x400478d1) = -1 ERRNO_111 (Connection refused)
close(3)                                = 0
sigprocmask(SIG_BLOCK, [ALRM], [USR1 IO]) = 0
sigaction(SIGALRM, {0x40062170, [], 0}, {SIG_DFL}) = 0
time(NULL)                              = 836692741
alarm(4)                                = 0
sigsuspend([USR1 IO] <unfinished ...>

(can someone tell me what ipc_subcall is?  I have no man page for
it...)

- Richard

---

From: Ian Jackson <[email-masked]>
Date: Wed, 10 Jul 96 01:18 BST

Richard Kettlewell writes ("Bug#3541: rlogin blocks on ECONNREFUSED!"):
...
> rsh and rcp display similar behaviour.

I've already reported this - bug 3190.  I see that Peter Tobias has
marked it as done, with the words:
} That's not a bug, it's a feature. The rcmd from the libc library is
} responsible for that delay. Miquel explained that feature a few weeks
} ago when there was a similar bug report (which I redirected to the libc
} library because the r-tools only use the rcmd function and I cannot   
} change that in the netstd package).                                  

I've been having a discussion with Miquel about this, and it looks
like it was most likely a silly workaround for a kernel bug, or
something.

In any case, it should be removed.

} I'll close your bug report with this mail because there is already    
} such a bug report against libc.                                                

I'm going to reopen it and merge it with the other report.  After all,
that's what the new `merge' feature is for.  I'll also reassign this
new one to the libc5 package.

Richard, I'll use your address in my `From' when I reopen it so that
you get to own it.

Ian.