| Title: | ase |
| Moderator: | SMURF::GROSSO |
| Created: | Thu Jul 29 1993 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2114 |
| Total number of notes: | 7347 |
HEllo all...
A customer is preparing a cluster for the telesector. In his 3 node cluster
with
2100 4100 4100 , he can only start the TeMIP Name Service "TNS" (
TFRTNSSRVV310 ) on the
2100 !! . If he tries to move the service to either 4100 , the port to use has
allready been taken by the submon process. If he stops it things move fine.
ASE submon aquires ports without looking up /etc/services
The following has been experienced with ASE V1.3 on Digital Unix V3.2G
Ingress standard setup reserves port 1000, submon complains.
ANY TAKERS ......
regards MArtin
Customer description:
Description:
------------
The process "submon" of the ASE cluster monitor aquires port 1000 without
checking that this port is really free.
The situation documented in the investigation note shows that it takes a port
legally owned by TNS. This causes TNS to malfunction.
Investigation Note
-----------------
cindy.dscc.dk # /usr/local/bin/lsof | grep submon
lsof: WARNING: /tmp/.lsof_dev_cache needs to be rebuilt; /dev is newer.
submon 313 root cwd VDIR 2516, 931666 8192 2 /
(root_domain#root)
submon 313 root txt VREG 2583, 675000 909312 14385 /usr
(usr_domain#usr)
submon 313 root 0r VDIR 2516, 931666 8192 2 /
(root_domain#root)
submon 313 root 1r VDIR 2516, 931666 8192 2 /
(root_domain#root)
submon 313 root 2r VDIR 2516, 931666 8192 2 /
(root_domain#root)
submon 313 root 3u inet 0x0b652700 0x0 TCP
cindy.dscc.dk:1008->cindy.dscc.dk:1022
submon 313 root 4u inet 0x0b653b00 0x0 TCP
cindy.dscc.dk:1007->cindy.dscc.dk:1022
submon 313 root 5u inet 0x0b652c00 0x0 TCP
cindy.dscc.dk:1006->cindy.dscc.dk:1022
submon 313 root 6r FIFO 0x3bdf8600 0 0
submon 313 root 7u inet 0x0a8ee000 0x0 TCP
localhost:1005->localhost:1017
submon 313 root 8u inet 0x3bac2b40 0x0 UDP *:914
submon 313 root 9w FIFO 0x3bdf9800 304 0
submon 313 root 10u unix 0x0a8ef500 0x0 ->(none)
submon 313 root 11u inet 0x093be400 0x0 TCP *:1004
submon 313 root 12u inet 0x093be900 0x0 TCP
cindy.dscc.dk:1003->cathy.dscc.dk:1023
submon 313 root 13u inet 0x093bf200 0x0 TCP
cindy.dscc.dk:1002->cindy.dscc.dk:1023
submon 313 root 14u inet 0x0c58d400 0x0 TCP
cindy.dscc.dk:tns->cindy.dscc.dk:1021
submon 313 root 15u inet 0x093bf300 0x0 TCP
cindy.dscc.dk:999->claudia.dscc.dk:1019
cindy.dscc.dk #
cindy.dscc.dk # tail /etc/services
kdebug 10401/tcp
cfgmgr 10402/tcp
dtspc 6112/tcp #subprocess control
dnacml 436/tcp # DECnet/OSI
### BEGIN TNS UPDATE
# THIS PART WILL BE REMOVED DURING DE-INSTALL OF TNS
# DO NOT INSERT MODIFICATIONS BETWEEN THESE FLAGS
tns_cml 437/tcp # TNS communication processing
tns 1000/tcp # TNS SERVER PORT
### END TNS UPDATE
cindy.dscc.dk #
[Posted by WWW Notes gateway]
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2090.1 | Problem isn't TNS | TAEC::STANARD | Bob Stanard - MCI/Mission Critical- CSC/Colorado | Thu May 29 1997 05:36 | 8 |
The problem is not TNS, but the ASE monitor process. TNS properly registers it's use of the TNS ports 1000 in /etc/services. The ASE software starts before TNS is ever started, and grabs the port it has reserved. The workaround for TeMIP is to change the port assignements for TNS to something that ASE won't grab. This is all described in the TeMIP notes conference on TAEC::TEMIP in note 722.0. Bob | |||||
| 2090.2 | Thanks a million | NNTPD::"[email protected]" | martin | Fri May 30 1997 05:54 | 6 |
I have read and handed over the information to the customer, We must then see when and what happens in the Trucluster group. Regards MArtin [Posted by WWW Notes gateway] | |||||
| 2090.3 | The Customer has implemented following solution. | NNTPD::"[email protected]" | martin + customer | Fri May 30 1997 09:26 | 12 |
CUSTOMER SOLUTION:: In /etc/rc.conf they have set cms_conf to off, and they have not seen any malfunctions. They would offcourse like to know if this is a problem , doing so, Other than they do not have the same type of logging fram the trace.d and submon. So things are running fine for them and their testing at DSC Communications regards MArtin [Posted by WWW Notes gateway] | |||||