From: alan@ernest.dseg.ti.com (Alan Edmonds)
Subject: Re: How to tell which process(es) have a given file/inode open under SVr4?
Organization: Texas Instruments, Inc. - Plano, Tx
Date: Wed, 22 Jul 1992 00:38:22 GMT
Keywords: File Process Inode Open SVR4

In article <1992Jul21.163221.1417@mjbtn.jobsoft.com> root@mjbtn.jobsoft.com (Mark J. Bailey [ADMIN]) writes:
>Hello,
>
>Sorry for the multi-group crosspost.  I was not sure where to look.

You got close enough.

[some stuff deleted]
>OK history aside, what is now happening is that the initial parameters
>on the ports in question are 9600 (and so on), ie, not what you would 
>expect, and after our open call and ioctl calls, NOTHING BLOODY CHANGES
>at all, our program output gets post processed (because for some reason
>OPOST [along with everything else] that we clear [which worked on the
>ports never having had terminal service] in not getting cleared), and 
>things are a mess.  

I'm not sure I understand your problem.  But here goes anyway.

This is normal behavior.  The ports will revert to what the kernal
wants them to be (300 baud, etc), when the LAST open terminates.
SO, you can open the port, dink with it, but when you close it BAM, 
back to 300 baud.  The "trick" is to keep the port open with 
something like "sleep 999999 </dev/ttynn &".  This will keep the port
open so when your setup terminates, the changes will keep.  You can 
test this by trying to change the port with stty and see if the changes
take.  Then do the same changes after running the sleep command above.


>I REMOVED ports services for the ports in question and no change.  We 
>contacted the software vendor for the other application that is also on
>this system, and to their knowledge, there is nothing in their package
>that would go out and open these ports AND KEEP THEM OPEN.  It is this
>concept of something, somewhere, that is opening these ports and 
>keeping them open (or somehow locked) (and thus preventing our ioctl's
>from having any effect) that we are now focusing on.  This is also
>supported by the fact that initial port parms should have a baud rate
>of 300.  On the ORIGINAL ports we used, as I said, they were initially
>300 baud, went to 9600 after our inits, then at close, immediately went
>back to 300 baud.

Stupid question, but I have to ask; What about getty? ttymon?

>This has turned into a longwinded hurl and I apologize!  :-)  Anyway,
>I would think that if a port had *NO* port service DEFINED (not just
>DISABLED), and no other process had it opened, it should be 300 baud.
>So, something has to have it and we are not sure how to tell whom.  Under
>SVr3 (SCO), the pstat command aided in locating open inodes and their
>opening processes.  But (and here is the real reason for my post), how
>do you do it under SVr4???????  :-)  And, maybe it is not what I am
>leaning towards at all and if you have another thought (anything!  :-)),
>we would be most appreciative to you!  If SVr4 was in house and used 
>everyday here, no biggie, I am sure, but this is one of those "HHhhmmm....
>how did I manage to get in this #^%#&^% mess?" situtations and we are
>stumped.
>
>Thank you for your time and endurance!
>
>Mark
>
>-- 
>Mark J. Bailey, N4XHX                              _______/====X11====\_______
>USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 |         JobSoft         |
>VOICE:  +1 615 893 0098                            | Design & Development Co.|
>UUCP:   ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb  |  Murfreesboro, TN  USA  |
>DOMAIN: mjb@mjbtn.JOBSOFT.COM      CIS: 76314,160  ---------------------------
><KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests@mjbtn.jobsoft.com>


-- 
Alan Edmonds                                     Texas Instruments, Inc.
I don't speak for TI; TI doesn't speak for me    M/S 8513
Work phone: (214)575-6427                        6620 Chase Oaks Blvd.
Email: alan@ernest.dseg.ti.com                   Plano, Texas  75023
Xref: sparky comp.unix.questions:9608 comp.unix.admin:4390