(This is not nessarily a programming question but hopefully somebody
here
knows the answer. The system is SunOS 5.8 Generic_108528-18 sun4u
sparc SUNW,Sun-Fire-480R.)
I thought a new process could not use a TCP port already used by
another process. But on an Oracle database server, two processes both
open 1522 on the same IP. They were started completely independent of
each other (not from a common parent that opened port 1522 earlier).

#TNS listener:
$ ps -fp 17413
UID PID PPID C STIME TTY TIME CMD
oracle 17413 1 0 01:49:00 ? 0:00 /export/home/oracle/
products/9205/bin/tnslsnr LISTENER -inherit
$ pfiles 17413
....
9: S_IFSOCK mode:0666 dev:284,0 ino:14870 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
sockname: AF_INET 0.0.0.0 port: 1522  <-- port 1522
....
15: S_IFSOCK mode:0666 dev:284,0 ino:17586 uid:0 gid:0 size:0
O_RDWR|O_NDELAY FD_CLOEXEC
sockname: AF_INET 10.17.127.159 port: 1522  <-- port 1522
peername: AF_INET 10.17.127.159 port: 45882

#Oracle dispatcher, which was started later:
$ ps -fp 17461
UID PID PPID C STIME TTY TIME CMD
oracle 17461 1 0 01:56:52 ? 0:00 ora_d002_DEVL
$ pfiles 17461
....
16: S_IFSOCK mode:0666 dev:284,0 ino:25387 uid:0 gid:0 size:0
O_RDWR|O_NDELAY FD_CLOEXEC
sockname: AF_INET 10.17.127.159 port: 1522  <-- port 1522
peername: AF_INET 10.240.36.68 port: 3838

So how can 17461 obtain port 1522 without throwing an error like
"Address already in use"?

I also did `truss -vall' on the new process (17461) when a client was
connecting to it. Its file descriptor 16 appeared all of a sudden:

17461: getsockname(16, 0xFFFFFFFF7FFFD0AC, 0xFFFFFFFF7FFFD0BC, 1) = 0
17461:    AF_INET name = 10.17.127.159 port = 1522

Thanks for any explanation.

Yong Huang

[ Post a follow-up to this message ]

might be child process which inherit and didnt close the fh.



On May 21, 9:11 am, yong...@yahoo.com wrote:
> (This is not nessarily a programming question but hopefully somebody
> here
> knows the answer. The system is SunOS 5.8 Generic_108528-18 sun4u
> sparc SUNW,Sun-Fire-480R.)
> I thought a new process could not use a TCP port already used by
> another process. But on an Oracle database server, two processes both
> open 1522 on the same IP. They were started completely independent of
> each other (not from a common parent that opened port 1522 earlier).
>
> #TNS listener:
> $ ps -fp 17413
> UID PID PPID C STIME TTY TIME CMD
> oracle 17413 1 0 01:49:00 ? 0:00 /export/home/oracle/
> products/9205/bin/tnslsnr LISTENER -inherit
> $ pfiles 17413
> ....
> 9: S_IFSOCK mode:0666 dev:284,0 ino:14870 uid:0 gid:0 size:0
> O_RDWR FD_CLOEXEC
> sockname: AF_INET 0.0.0.0 port: 1522  <-- port 1522
> ....
> 15: S_IFSOCK mode:0666 dev:284,0 ino:17586 uid:0 gid:0 size:0
> O_RDWR|O_NDELAY FD_CLOEXEC
> sockname: AF_INET 10.17.127.159 port: 1522  <-- port 1522
> peername: AF_INET 10.17.127.159 port: 45882
>
> #Oracle dispatcher, which was started later:
> $ ps -fp 17461
> UID PID PPID C STIME TTY TIME CMD
> oracle 17461 1 0 01:56:52 ? 0:00 ora_d002_DEVL
> $ pfiles 17461
> ....
> 16: S_IFSOCK mode:0666 dev:284,0 ino:25387 uid:0 gid:0 size:0
> O_RDWR|O_NDELAY FD_CLOEXEC
> sockname: AF_INET 10.17.127.159 port: 1522  <-- port 1522
> peername: AF_INET 10.240.36.68 port: 3838
>
> So how can 17461 obtain port 1522 without throwing an error like
> "Address already in use"?
>
> I also did `truss -vall' on the new process (17461) when a client was
> connecting to it. Its file descriptor 16 appeared all of a sudden:
>
> 17461: getsockname(16, 0xFFFFFFFF7FFFD0AC, 0xFFFFFFFF7FFFD0BC, 1) = 0
> 17461:    AF_INET name = 10.17.127.159 port = 1522
>
> Thanks for any explanation.
>
> Yong Huang

[ Post a follow-up to this message ]

In article <1179723216.382349.120100@u36g2000prd.googlegroups.com>,
phonbus@gmail.com wrote:

> might be child process which inherit and didnt close the fh.

That's directly contradicted by what he wrote:
[vbcol=seagreen] 

Also, if the fh were inherited, the ID would be the same, but it's 15 in
one process and 16 in the other.
[vbcol=seagreen]
>
>
>
> On May 21, 9:11 am, yong...@yahoo.com wrote: 

Notice that the peernames are different.
[vbcol=seagreen] 

Do the two processes communicate with each other via a named pipe or
Unix-domain socket?  If so, the listener can send open sockets to the
dispatcher via sendmsg().

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

On May 21, 2:30 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <1179723216.382349.120...@u36g2000prd.googlegroups.com>,
>
>  phon...@gmail.com wrote: 
>
> That's directly contradicted by what he wrote:
> 
>
> Also, if the fh were inherited, the ID would be the same, but it's 15 in
> one process and 16 in the other.
>
>
>
>
> 
> 
> 
> 
>
> Notice that the peernames are different.
>
>
> 
> 
>
> Do the two processes communicate with each other via a named pipe or
> Unix-domain socket?  If so, the listener can send open sockets to the
> dispatcher via sendmsg().
>
> --
> Barry Margolin, bar...@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
> *** PLEASE don't copy me on replies, I'll read them in the group ***

[Repost. Google Groups didn't do it even if it said it posted my
message.]

Thank you, Barry. You're right. There was a UNIX domain socket. That
must be how the open socket file descriptor was sent to the
dispatcher. I didn't see sendmsg() call though. Maybe it's done
through some ioctl() action.

I posted the same message to comp.unix.solaris and was recommended to
read http://www.myelin.co.nz/post/2003/12/2/. I then searched for
"file descriptor passing" on Google and found a lot of articles.

Thanks again.

Yong Huang

[ Post a follow-up to this message ]