njh@root44.UUCP (05/25/83)
Relay-Version:version B 2.10 5/3/83; site mhuxt.UUCP Message-ID:<2179@root44.UUCP> Date:Wed, 25-May-83 10:02:12 EDT 1) Well we all have to start somewhere. 2) No, I couldn't believe I was actually reading it either. Nigel Horne ...!vax135!ukc!root44!njh
grunwald@uiucdcs.UUCP (05/27/83)
Relay-Version:version B 2.10 5/3/83; site mhuxt.UUCP Message-ID:<2148@uiucdcs.UUCP> Date:Thu, 26-May-83 22:35:40 EDT #R:iuvax:-38700:uiucdcs:13700034:000:362 uiucdcs!grunwald May 26 18:57:00 1983 After such a display of tact, I can imagine the reluctance that people have to ask questions in this news group. What is the new UNIX manager supposed to do when he has a problem like this? Certainly, getting responses like the previous ones aren't whats needed. You could have answered his question in the space and time it took you to belittle his question.
vahe@iuvax.UUCP (06/01/83)
Yes, somebody took the time to "set that guy straight"; mainly, myself. The reason I posted to the net was that we had had renegade inits for a couple of days (trying to reboot while the system was still up....), which turned out to be an easily corrected problem (somebody typing "init -" while SU!). When I saw the five inits idle, I was so exasperated that I thought this was a genuine bug. I certainly didn't expect the kind of response I got. Out of the deluge of responses I received, all except one re-read init(8) to me. That one person was the only one who gave me enough credit, and said something like: "well, this is the normal order of things; if it doesn't apply, I don't know what your problem is". Nobody else bothered wondering if I did have a genuine problem. Yes, I should've phrased my question more carefully. I just didn't think there were people on the net immature enough to retort as they did. Vahe Sarkissian
wcs@hou2b.UUCP (06/03/83)
There was a recent discussiion that went as follows: J. Novice Wizard: Why do I have so many inits? Subset of World: Flame! Flame! Flame! When I was using USG UNIX, there was only one init, but lots of gettys. Now that I use Berkeley 4.1, I seem to have gettys on hardwired terminals and inits on dialups, at least mostly. At the risk of inviting more flames, can I assume this is ok? (Silence implies consent, but I borrowed an asbestos keyboard to display my ignorance safely.) Thanks; Bill Stewart hou2b!hoscf!bin
dyer@wivax.UUCP (06/03/83)
Re: /etc/init appears on dialup lines, /etc/getty appears on hard-wired lines. The reason for this is that init performs the open of the terminal device, followed by dup(0), dup(0), generating file handle 0, 1, and 2 aka STDIN, STDOUT and STDERR.) An open on a dialup line blocks until carrier is detected, whereas an open on a hard-wired line succeeds immediately. In both cases, after the open and dup's, init executes /etc/getty.
mjb@brunix.UUCP (06/03/83)
Well, well, well. So iuvax!vahe isn't a rank novice after all, and it turns
out the "presumptuous" people were all the well-meaning "teachers" who assumed
he can't read the manual! For the record, my colleagues and I were splitting
a gut not over iuvax!vahe's predicament, nor at his level of expertise, but
rather at the beauty of the prose used to describe the situation. To wit:
"I've tried killing them with KILL signals, but they
just pop right back, swap out, and sit there."
Pure poetry! As a matter of interest, while the net was clogged with postings
from self-styled pomposity exorcists, the mail I received was all of the "I
got a laugh out of it, too" variety.
No, I didn't attempt to "set the guy straight". As a rule, I only reply to
pleas for help if I think I can add some particular insight to the problem;
I am certainly beyond the stage where I have to prove my "wizard credentials"
to anyone. This is not to put down anyone who did reply (except, of course,
for ritcv!bozo), and I thought iuvax!vahe was rather rude to do so.
Flame all you want, it's still the funniest thing I've ever read on the net,
and I'm not afraid to admit it!
Mike Braca, Brown CS, {decvax,ihnp4,allegra}!brunix!mjb, mjb.brown@udel-relaysmh@mit-eddi.UUCP (06/03/83)
I was one of the wizards who politely replied to the original query explaining how many init's was perfectly normal. (I do resent the implication that it was wrong for me to present the obvious information to someone who appeared to be a beginner -- but let that pass...) Let's deal with technical issues, which are much more fun. If the extra inits were created by someone running them from shell level explicitly, how is it that they couldn't be killed? In the original query, I naturally assumed that the inits were being recreated with new process numbers by the master init, but now I'm not so sure... Perhaps Vahe could explain what gives?
smk@linus.UUCP (Steven M. Kramer) (06/05/83)
Surprise! This is NOT a flame. This applies to 4.1bsd: init appears on each terminal that is modem-controlled and the carrier has not yet been established. The associated terminal is ? since in the open routines for the device, the controlling tty is determined AFTER the hardware open is done. For the direct connects, the carrier is always established, init does its work, and then calls getty. getty then proceeds until it outputs login: and does a read for the login name (which it will pass to login as an arg. That's why when using modem-controlled lines, the login: appears automatically after you connect, and why on direct connects, you have to hit return to see login: (because it already did that and is now waiting for your name). With direct connects, since it's waiting for input, you can just type your name as long as no garbage was produced after you turned your terminal on. We needed to know this cause we put a timeout feature into both login and getty. 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. Also, uucp administrators should know this behavior for the sites they call. If hardwired to modems (such lines are stupid, prone to security attack, but they exist out there), put in an extra "" "" in the L.sys line, otherwise use the std login: or gin--gin stuff directly. When I connect to a site for the first time, I use cu to find out what type of line behavior it is on the other end and set up accordingly. This is better than having uucp timeout if the original login: doesn't appear (at today's phone costs, no wonder Bell encourages such hookups). --steve
chris.umcp-cs%udel-relay@sri-unix.UUCP (06/06/83)
From: Chris Torek <chris.umcp-cs@udel-relay> From: 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<system> -x<debug-level> & (where <system> is the name of the site, and <debug-level> 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
richl@tektronix.UUCP (06/12/83)
I don't think anybody is in a position to laugh at anyone else's question, whether they are a wizard or not. The least you can do if you laugh, is to laugh to yourself, but not publicly. Unix-wizards should be a forum for those less in the know to gain from those more in the know. Just because a question didn't deal with a XYZ99 driver or a PU88 tape drive or some such "higher-level" topic doesn't mean it is not worthy of answering politely. To the original submitter: I'm glad you asked. While everybody was snickering at the question, I, too, was wondering what the answer was. I had some ideas about the answer, but had never been sure myself. If I ever need to ask a question, I certainly hope it is worthy of somebody's POLITE reply. Rick Lindsley richl@tektronix ..!zehntel!tektronix!richl t
ricks@ucbcad.UUCP (06/13/83)
#R:iuvax:-38700:ucbcad:2600002:000:408 ucbcad!ricks Jun 5 16:52:00 1983 In reply to Mike Bracas' comment: I am certainly beyond the stage where I have to prove my "wizard credentials" to anyone. A little presumptuous, isn't it Mike. I've never even heard of you, nor have any of the people I've talked to around here. Better start sending out more "I'm a wizard" messages, lest we forget about you...... Rick L Spickelmier ucbvax!ricks ricks@berkeley