[comp.unix.i386] getty..not hanging up

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!>