Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!genrad!grkermit!mit-vax!eagle!harpo!seismo!hao!hplabs!sri-unix!chris.umcp-cs@udel-relay From: chris.umcp-cs%udel-relay@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: Too many inits Message-ID: <1817@sri-arpa.UUCP> Date: Mon, 6-Jun-83 08:04:30 EDT Article-I.D.: sri-arpa.1817 Posted: Mon Jun 6 08:04:30 1983 Date-Received: Wed, 8-Jun-83 14:47:47 EDT Lines: 49 From: Chris TorekFrom: harpo!eagle!mit-vax!mit-eddi!genrad!linus!smk@ucb-vax ... cause we put a timeout feature into both login and getty. I thought 4.1bsd login had a timeout. O well, maybe we put it locally. We could only do this to modem-controlled lines, because the direct ones would timeout and start another init-getty, timeout ... The modem lines would start init and wait on the open. The former wastes much cpu time and process #'s especially for low timeout periods, and the latter is more like what we wanted. We were mainly concerned about people calling up, going out for coffee, and leaving a shared line (crucial to us) open. That's what we've got: only auto-bauding lines (and all our dialups are auto-bauding lines) time out. Also, uucp administrators should know this behavior for the sites they call. It's probably best to ask someone at the site you're calling, rather than just dialing up the line and trying something. Often what works fine for someone using a modem doesn't work quite right for uucp, because of silly things like uucp sending newlines, not carriage returns. Our auto-baud code (in getty) only recognizes carriage returns; if you called us up and hit return you'd get the login prompt, and then perhaps assume that one "" "" entry in L.sys will work. Uucp administrators should also know about the -x option to uucico. If you're having trouble dialing a site, you can run /usr/lib/uucp/uucico -r1 -s -x & (where is the name of the site, and is a single digit between 1 and 9) and watch what happens. Debug levels 6 (I think) to 9 show what's going on during those L.sys entries, so you can see what you're getting back from the remote system. Very handy for tracking down noise problems, or if the other end is at the wrong baud rate, etc. But you should warn the other site you're doing this; it makes a debug log on their end, which they may want to clean out afterwards. - Chris