campbell@redsox.UUCP (Larry Campbell) (02/10/89)
Often (maybe 50% of the time), when uucico attempts to dial out, it successfully opens the tty line (the DTR light on the modem comes on) and then gives up, closes the tty line, and retries, giving the debug message "lost line errno - 0". If there's only one eligible tty line, this isn't a problem, since it retries and ALWAYS works the second time. But if there are two (or more) eligible lines, it will give up on the first one and use the second one instead. This is in the HDB uucp (BNU) included with S5R3.0 (Interactive 386/ix 1.0.6). Any ideas? Is this just a bug I have to put up with? -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
gregg@ihlpb.ATT.COM (Wonderly) (02/13/89)
From article <590@redsox.UUCP>, by campbell@redsox.UUCP (Larry Campbell): > Often (maybe 50% of the time), when uucico attempts to dial out, > it successfully opens the tty line (the DTR light on the modem comes > on) and then gives up, closes the tty line, and retries, giving the > debug message "lost line errno - 0". If there's only one eligible > tty line, this isn't a problem, since it retries and ALWAYS works > the second time. But if there are two (or more) eligible lines, it > will give up on the first one and use the second one instead. When I was at school we had a similar problem that was directly related to reboot's. Apparently there is one particular bit of hardware status or perhaps a software flag that is not initialized properly by uucico i.e. getty gets it right, but uucico doesn't. The close(2) call evidently did something to straighten things out so that succeeding attempts worked. We never really fixed the problem, we just used kermit to attempt an outbound connection on each line right after boot. -- Gregg Wonderly DOMAIN: gregg@ihlpb.att.com AT&T Bell Laboratories UUCP: att!ihlpb!gregg