home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9501 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  2.5 KB
  1. Path: sparky!uunet!utcsri!bonnie.concordia.ca!clyde.concordia.ca!altitude!Nyongwa.CAM.ORG!steve
  2. From: steve@Nyongwa.CAM.ORG (Steve M. Robbins)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: getty_ps and modem carrier loss
  5. Keywords: getty, modem, dialup
  6. Message-ID: <BtMM4q.16z8@Nyongwa.CAM.ORG>
  7. Date: 27 Aug 92 05:05:14 GMT
  8. References: <k-+n=9m.james@netcom.com> <1992Aug22.162204.135@cpumagic.scol.pa.us>
  9. Organization: Chiral Symmetry Breaking, Inc.
  10. Lines: 44
  11.  
  12. In article <1992Aug22.162204.135@cpumagic.scol.pa.us> mloewen@cpumagic.scol.pa.us (Michael C. Loewen) writes:
  13. >In article <k-+n=9m.james@netcom.com> james@netcom.com (James L. Paul) writes:
  14. >>I'm using uugetty and getty from the getty_ps package with Linux 0.97.1
  15. >>Everything is working great, dialups are easy and the autobaud method is
  16. >>'charming.' However, I'm having trouble getting the shell (or whatever the
  17. >>current parent process is) to die when modem carrier is lost before logout.
  18. [..]
  19. >
  20. >   Check your /etc/gettydefs file, and make sure the entry you're using has
  21. >'HUPCL' added to it.  I'm running getty_ps on a SVR4 system, with the modem
  22. >locked at 19200 baud.  Here's an entry from my gettydefs:
  23. >
  24. >19200USR# B19200 OPOST ONLCR TAB3 BRKINT IGNPAR IXON IXANY ISTRIP ECHO ECHOE 
  25. >ECHOK ICANON ISIG HUPCL CS8 CREAD # B19200 OPOST ONLCR TAB3 BRKINT IGNPAR IXON 
  26. >IXANY ISTRIP ECHO ECHOE ECHOK ICANON ISIG HUPCL CS8 CREAD #login: #19200USR
  27.  
  28. Yeah, I guess that's one way.  A shorter way is using the 'SANE' settings,
  29. which does include HUPCL.
  30.  
  31. Are others having this problem?
  32.  
  33. Last week A. Rumble posted about this, so I logged in to my system over the
  34. modem and dropped carrier several times.  Every time the shell died, even
  35. if I was running another program like elm or rn. 
  36.  
  37. Then I tried doing weird things like starting a bunch of shells (bash; wait
  38. for the prompt; bash; wait for the prompt; bash...), or running login to login
  39. as another user.  A couple of times when I did this, some, but not all of
  40. the shells I started died, leaving two or three running, and of course, no
  41. getty.
  42.  
  43. I guess I should see if this is repeatable.  But it's late now, and I was
  44. just wondering if anyone had an idea of what's going on.
  45.  
  46. Doesn't the signal go to the process that originally opened the device?
  47. That would be the original shell (exec'd from getty) so why would hanging up
  48. kill off some of the newer shells, but leave the old one running??
  49.  
  50. Steve
  51.  
  52. -- 
  53. Steve Robbins  --  steve@nyongwa.cam.org
  54. I asked Hank Williams "how lonely does it get?"
  55. Hank Williams hasn't answered yet.
  56.