home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / question / 9265 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  4.3 KB
  1. Xref: sparky comp.unix.questions:9265 comp.unix.sysv386:12223 comp.unix.programmer:3839 comp.unix.wizards:3274
  2. Newsgroups: comp.unix.questions,comp.unix.sysv386,comp.unix.programmer,comp.unix.wizards
  3. Path: sparky!uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!m2.dseg.ti.com!ernest!alan
  4. From: alan@ernest.dseg.ti.com (Alan Edmonds)
  5. Subject: Re: How to tell which process(es) have a given file/inode open under SVr4?
  6. Organization: Texas Instruments, Inc. - Plano, Tx
  7. Date: Wed, 22 Jul 1992 00:38:22 GMT
  8. Message-ID: <BrrLrz.MxI@ernest.dseg.ti.com>
  9. Keywords: File Process Inode Open SVR4
  10. References: <1992Jul21.163221.1417@mjbtn.jobsoft.com>
  11. Lines: 73
  12.  
  13. In article <1992Jul21.163221.1417@mjbtn.jobsoft.com> root@mjbtn.jobsoft.com (Mark J. Bailey [ADMIN]) writes:
  14. >Hello,
  15. >
  16. >Sorry for the multi-group crosspost.  I was not sure where to look.
  17.  
  18. You got close enough.
  19.  
  20. [some stuff deleted]
  21. >OK history aside, what is now happening is that the initial parameters
  22. >on the ports in question are 9600 (and so on), ie, not what you would 
  23. >expect, and after our open call and ioctl calls, NOTHING BLOODY CHANGES
  24. >at all, our program output gets post processed (because for some reason
  25. >OPOST [along with everything else] that we clear [which worked on the
  26. >ports never having had terminal service] in not getting cleared), and 
  27. >things are a mess.  
  28.  
  29. I'm not sure I understand your problem.  But here goes anyway.
  30.  
  31. This is normal behavior.  The ports will revert to what the kernal
  32. wants them to be (300 baud, etc), when the LAST open terminates.
  33. SO, you can open the port, dink with it, but when you close it BAM, 
  34. back to 300 baud.  The "trick" is to keep the port open with 
  35. something like "sleep 999999 </dev/ttynn &".  This will keep the port
  36. open so when your setup terminates, the changes will keep.  You can 
  37. test this by trying to change the port with stty and see if the changes
  38. take.  Then do the same changes after running the sleep command above.
  39.  
  40.  
  41. >I REMOVED ports services for the ports in question and no change.  We 
  42. >contacted the software vendor for the other application that is also on
  43. >this system, and to their knowledge, there is nothing in their package
  44. >that would go out and open these ports AND KEEP THEM OPEN.  It is this
  45. >concept of something, somewhere, that is opening these ports and 
  46. >keeping them open (or somehow locked) (and thus preventing our ioctl's
  47. >from having any effect) that we are now focusing on.  This is also
  48. >supported by the fact that initial port parms should have a baud rate
  49. >of 300.  On the ORIGINAL ports we used, as I said, they were initially
  50. >300 baud, went to 9600 after our inits, then at close, immediately went
  51. >back to 300 baud.
  52.  
  53. Stupid question, but I have to ask; What about getty? ttymon?
  54.  
  55. >This has turned into a longwinded hurl and I apologize!  :-)  Anyway,
  56. >I would think that if a port had *NO* port service DEFINED (not just
  57. >DISABLED), and no other process had it opened, it should be 300 baud.
  58. >So, something has to have it and we are not sure how to tell whom.  Under
  59. >SVr3 (SCO), the pstat command aided in locating open inodes and their
  60. >opening processes.  But (and here is the real reason for my post), how
  61. >do you do it under SVr4???????  :-)  And, maybe it is not what I am
  62. >leaning towards at all and if you have another thought (anything!  :-)),
  63. >we would be most appreciative to you!  If SVr4 was in house and used 
  64. >everyday here, no biggie, I am sure, but this is one of those "HHhhmmm....
  65. >how did I manage to get in this #^%#&^% mess?" situtations and we are
  66. >stumped.
  67. >
  68. >Thank you for your time and endurance!
  69. >
  70. >Mark
  71. >
  72. >-- 
  73. >Mark J. Bailey, N4XHX                              _______/====X11====\_______
  74. >USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 |         JobSoft         |
  75. >VOICE:  +1 615 893 0098                            | Design & Development Co.|
  76. >UUCP:   ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb  |  Murfreesboro, TN  USA  |
  77. >DOMAIN: mjb@mjbtn.JOBSOFT.COM      CIS: 76314,160  ---------------------------
  78. ><KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests@mjbtn.jobsoft.com>
  79.  
  80.  
  81. -- 
  82. Alan Edmonds                                     Texas Instruments, Inc.
  83. I don't speak for TI; TI doesn't speak for me    M/S 8513
  84. Work phone: (214)575-6427                        6620 Chase Oaks Blvd.
  85. Email: alan@ernest.dseg.ti.com                   Plano, Texas  75023
  86.