tim@comcon.UUCP (Tim Brown) (12/22/89)
I am running ISC2.0.2, tcp, nfs (off right now) and a computone inteliport board. What would cause getty to *sometimes* not hang up the phne when a user logs off? Note, most of the time it works fine and the user hits ctrl-d and the phone connection is broken, ie dtr is being handled. But right now it isn't hanging up, when a user hits ctrl-d they get another login: and have to hangup manually at thier end. The wierd thing is I am not changing anything. Any ideas? Tim Brown | Computer Connection | (attmail or uunet)!comcon!tim |
fischer@utower.gopas.sub.org (Axel Fischer) (12/24/89)
tim@comcon.UUCP (Tim Brown) writes: >What would cause getty to *sometimes* not hang up the phne when a user >logs off? Note, most of the time it works fine and the user hits ctrl-d >and the phone connection is broken, ie dtr is being handled. But right >now it isn't hanging up, when a user hits ctrl-d they get another login: >and have to hangup manually at thier end. >The wierd thing is I am not changing anything. >Any ideas? This happens always when you start a process in the background. E.g. if you send a mail to someone and the mailer processes the mail in the background and you quickly logout than you get a fresh login message, 'cause there is a process still running. You could also do this with a simple "tail -f .cshrc &" If you start it and logs off you will always get a fresh login message until you kill the process. -Axel -- fischer@utower.gopas.sub.org / fischer@db0tui6.BITNET / fischer@tmpmbx.UUCP Bang-Europe : ...!{doitcr,gopnbg,tmpmbx}!utower!fischer Bang-USA : ...!uunet!unido!gopnbg!utower!fischer Too low for zero ...
sauron@dsoft.UUCP (Ron Stanions) (12/25/89)
In article <196@comcon.UUCP> tim@comcon.UUCP (Tim Brown) writes: > ... >What would cause getty to *sometimes* not hang up the phne when a user >logs off? In your instance, you'll probably find that the stty settings on your com port are set to -hupcl. Look in your /etc/gettydefs and make sure that in all of your modem's baud-rate cycles you have it so that 'hupcl' is included in the second and third parameter sections of each line. For example, if a user logs on at 2400 baud the system may hang him up okay, but a user on 1200 uses a different setup line in gettydefs. By default the 386/ix system seems not to set hupcl either way, and I've had similar problems. by forcing it to hupcl, my modems have disconnected the users successfully every time so far. -- Ron Stanions -- sauron@dsoft \_/\--/\_/ All things posted by me are dsoft system administrator < \ / > by-products of a deranged mind Dragonsoft Development \ / from spending too many hours ...!uunet!tronsbox!dsoft!sauron `\oo/' trying to make uucp work!
roy@comcon.UUCP (Roy M. Silvernail) (12/29/89)
In article <NSSGK+@utower.gopas.sub.org>, fischer@utower.gopas.sub.org (Axel Fischer) writes: > tim@comcon.UUCP (Tim Brown) writes: > [about a getty not always hanging up on a logout] > > This happens always when you start a process in the background. > [...] > You could also do this with a simple "tail -f .cshrc &" > If you start it and logs off you will always get a fresh login message > until you kill the process. (ob disclaimer... Tim is my sysadmin;-) I just tried this exact procedure. (tail -f .bashrc &, running a bash shell) ps reported a shell and a tail in the background. I typed 'bye' and the system dropped carrier. I don't think it's specific to bash shell, though, because the Bourne shell would act the same way, and _sometimes_, the system would not hang up the modem. On the bright side, it doesn't seem to be happening as frequently now:-) -- _R_o_y _M_. _S_i_l_v_e_r_n_a_i_l | UUCP: uunet!comcon!roy | "Every race must arrive at this #include <opinions.h>;#define opinions MINE | point in its history" SnailMail: P.O. Box 210856, Anchorage, | ........Mr. Slippery Alaska, 99521-0856, U.S.A., Earth, etc. | <Ono-Sendai: the right choice!>
karl@ddsw1.MCS.COM (Karl Denninger) (12/29/89)
In article <NSSGK+@utower.gopas.sub.org> fischer@utower.gopas.sub.org writes: >tim@comcon.UUCP (Tim Brown) writes: > >>What would cause getty to *sometimes* not hang up the phne when a user >>logs off? Note, most of the time it works fine and the user hits ctrl-d >>and the phone connection is broken, ie dtr is being handled. But right >>now it isn't hanging up, when a user hits ctrl-d they get another login: >>and have to hangup manually at thier end. >>The wierd thing is I am not changing anything. >>Any ideas? > >This happens always when you start a process in the background. >E.g. if you send a mail to someone and the mailer processes the mail >in the background and you quickly logout than you get a fresh login >message, 'cause there is a process still running. > >You could also do this with a simple "tail -f .cshrc &" >If you start it and logs off you will always get a fresh login message >until you kill the process. Not necessarially. I have had it happen for NO explainable reason. There certainly isn't anything running in the background here for me right now, yet I still have the problem. There's something ELSE strange going on there..... Besides, what if you do a "nohup xxxxxxx &" then disconnect? That >should< work ok, and let you disconnect the line. If it doesn't then I'd say that something is broken; that's the intent of nohup! -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
sauron@dsoft.UUCP (Ron Stanions) (12/30/89)
In article <1989Dec29.151924.6810@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >In article <NSSGK+@utower.gopas.sub.org> fischer@utower.gopas.sub.org writes: >>tim@comcon.UUCP (Tim Brown) writes: >> >>>What would cause getty to *sometimes* not hang up the phne when a user >>>logs off? ... Well, I've usually found that somehow the 'hupcl' flag in stty got unset. any process run from the login shell that uses ioctl() to play with stdin/out can do this to you. Also, as mentioned before, when a program is running and any portion of it is still attached to stdin/out (eg, a program shelled with '&' loses stdin, but not stdout) that too will probably prevent DTR from dropping on the modem, since when you hang up, you won't be the last close to the i/o. (Note that some of these things I say here are educated guesses concerning stdin/out, and not hardcore fact.) If you get a situation that's consistant, try typing 'stty hupcl' just before you disconnect (or stty -a to view params and see if hupcl is set or not), or if you have any tasks running, shell them off AND redirect their output to /dev/null or somesuch. -- Ron Stanions -- sauron@dsoft \_/\--/\_/ All things posted by me are dsoft system administrator < \ / > by-products of a deranged mind Dragonsoft Development \ / from spending too many hours ...!uunet!tronsbox!dsoft!sauron `\oo/' trying to make uucp work!
tim@comcon.UUCP (Tim Brown) (12/31/89)
In article <1989Dec29.151924.6810@ddsw1.MCS.COM>, karl@ddsw1.MCS.COM (Karl Denninger) writes: > >tim@comcon.UUCP (Tim Brown) writes: > > > >>What would cause getty to *sometimes* not hang up the phne when a user > >>logs off? Note, most of the time it works fine and the user hits ctrl-d > [ more about the problem ] > I have had it happen for NO explainable reason. There certainly isn't > anything running in the background here for me right now, yet I still have > the problem. > > There's something ELSE strange going on there..... > Yes, there certainly is.. Right now, my system is functioning perfectly. It is hanging up fine. I haven't a clue as yet as to why to will sometimes revert. All I did was re-boot. Tim Brown | Computer Connection | (attmail or uunet)!comcon!tim |
fischer@utower.gopas.sub.org (Axel Fischer) (01/03/90)
roy@comcon.UUCP (Roy M. Silvernail) writes: >In article <NSSGK+@utower.gopas.sub.org>, fischer@utower.gopas.sub.org (Axel Fischer) writes: >> tim@comcon.UUCP (Tim Brown) writes: >> [about a getty not always hanging up on a logout] >> >> This happens always when you start a process in the background. >> [...] >> You could also do this with a simple "tail -f .cshrc &" >> If you start it and logs off you will always get a fresh login message >> until you kill the process. >I just tried this exact procedure. (tail -f .bashrc &, running a bash >shell) ps reported a shell and a tail in the background. I typed 'bye' >and the system dropped carrier. I don't think it's specific to bash >shell, though, because the Bourne shell would act the same way, and >_sometimes_, the system would not hang up the modem. Hmmm, I *always* used this trick to stay online on a dialup '286 Xenix System to get a fresh login. (saves telephon costs :-) Could anyone enlighten me why it shouldn't work on all systems ? -Axel -- fischer@utower.gopas.sub.org / fischer@db0tui6.BITNET / fischer@tmpmbx.UUCP Bang-Europe : ...!{doitcr,gopnbg,tmpmbx}!utower!fischer Bang-USA : ...!uunet!unido!gopnbg!utower!fischer Too low for zero ...
roy@comcon.UUCP (Roy M. Silvernail) (01/05/90)
In article <A$1C1*@utower.gopas.sub.org>, fischer@utower.gopas.sub.org (Axel Fischer) writes: | roy@comcon.UUCP (Roy M. Silvernail) writes: | >I just tried this exact procedure. (tail -f .bashrc &, running a bash | >shell) ps reported a shell and a tail in the background. I typed 'bye' | >and the system dropped carrier. | | Hmmm, I *always* used this trick to stay online on a dialup '286 | Xenix System to get a fresh login. (saves telephon costs :-) If all you want is a fresh login, try 'exec login' (or 'exec bash -login' in my case ;-) -- _R_o_y _M_. _S_i_l_v_e_r_n_a_i_l | UUCP: uunet!comcon!roy | "Every race must arrive at this #include <opinions.h>;#define opinions MINE | point in its history" SnailMail: P.O. Box 210856, Anchorage, | ........Mr. Slippery Alaska, 99521-0856, U.S.A., Earth, etc. | <Ono-Sendai: the right choice!>