./uv -admin -clearsockets not working on v8 ?

[jtsoong]

Hi,

I have a problem with dsrpc daemon not starting atm when i start my server.

I looked through the forums and found that when i run 'netstat | grep dsrpc' there are two ports open in the "CLOSE_WAIT" state.

I found another thread on here saying that these can be fixed by running:
./uv -admin -clearsockets

The ./uv command doesn't allow this option, has ./uv changed in v8?

If so, does anyone know which option would work now?

I also found an "ipcs | grep dstage" finds a lot of shared memory locked.. (like ~20 entries). Can this be cleared with the: "./uv -admin -reset" option? - this says it will reinitialize shared memory.

Any help would be most appreciated.

cheers

Jon

[jtsoong]

oh i found some more info!

So my netstat returns:
$> netstat | grep dsrpc
machine.dsrpc a1.machine.com.au.34836 64088 0 49232 0 CLOSE_WAIT
machine.dsrpc a1.machine.com.au.53649 64088 0 49232 0 CLOSE_WAIT

So there are two open CLOSE_WAIT ports, when i do a 'ipcs -mop', i get
a whole bunch of entries for shared memory that is used by my dstage user.

HOWEVER!, all of them except for two have the NATTCH column set as zero.

i.e. there are two shared memory segments still being attached to. Is it fair to assume that they are the two that are causing my CLOSE_WAITs ???

If so, is it a big problem to try to remove them using ipcrm ???
(From what i understand you should probably not 'ipcrm' memory that has a NATTCH != 0)???

[lstsaur]

To fix "CLOSE_WAIT" ports for dsrpc, you do the following:
1. lsof -P |grep 31538
2. Find the PID
3. Kill the PID
4. Restart the DS.

[jtsoong]

hmm i don't have lsof (solaris 9).

i'm wondering if i can just ipcrm the two shared memory entries that have NOATTCH !=0 ...

i'm not sure if this will break anything else

[ArndW]

If you have alread shut down datastage, then you can use "ipcrm -m" to get rid of those two entries. FIN_WAIT and CLOSE_WAIT status on Solaris are set to timeout after a given period of time, use "ndd -get /dev/tcp tcp_time_wait_interval" to get the timed wait interval and "ndd -get /dev/tcp tcp_fin_wait_2_flush_interval" to get the FIN_WAIT2 (and the CLOSE_WAIT, I think). These values are in milliseconds, but it can be a looong wait.

[ray.wurlod]

I have a vague memory that the tcp times reported by ndd are in microseconds (rather than milliseconds), but would be happy to be corrected.

[jtsoong]

i also found (with the server shutdown)

$> ps -ef | grep dsapi
dsadm 3782 29764 0 10:38:43 pts/1 0:00 grep dsapi
dsadm 8182 1 0 May 24 ? 0:12 dsapi_slave 8 7 0
dsadm 6493 1 0 May 24 ? 4:02 dsapi_slave 8 7 0

However a normal kill does nothing to these processes. They remain alive.

How bad is it to "kill -9" them?

[chulett]

With the server shut down? I don't believe that would be a problem. You may still have to manually clear any shared memory segments and 'hung' ports that remain before it will restart, however.

[jtsoong]

ok thanks

i did just that

[ArndW]

From the SUN Solaris Wiki pages:

A TCP connection enters TIME_WAIT as a result of the connection being terminated by one or both sides. If a TCP connection is in TIME_WAIT state and the remote transmits data, the side having the TCP connection in TIME_WAIT state sends a RST to indicate that data was lost. tcp_time_wait_interval is the length of time in milliseconds a TCP connection can remain in the TIME_WAIT state. The parameter is reported and set in milliseconds.

[ray.wurlod]

Just curious: can someone post the relevant bits from man ndd ?

[ArndW]

$ man ndd
Reformatting page. Please Wait... done

System Administration Commands ndd(1M)

NAME
ndd - get and set driver configuration parameters

SYNOPSIS
ndd [-set] driver parameter [value]

DESCRIPTION
ndd gets and sets selected configuration parameters in some
kernel drivers. Currently, ndd only supports the drivers
that implement the TCP/IP Internet protocol family. Each
driver chooses which parameters to make visible using ndd.
Since these parameters are usually tightly coupled to the
implementation, they are likely to change from release to
release. Some parameters may be read-only.

If the -set option is omitted, ndd queries the named driver,
retrieves the value associated with the specified parameter,
and prints it. If the -set option is given, ndd passes
value, which must be specified, down to the named driver
which assigns it to the named parameter.

By convention, drivers that support ndd also support a spe-
cial read-only parameter named ``?'' which can be used to
list the parameters supported by the driver.

EXAMPLES
Example 1: Getting Parameters Supported By The TCP Driver

To see which parameters are supported by the TCP driver, use
the following command:

example% ndd /dev/tcp \?

The parameter name ``?'' may need to be escaped with a
backslash to prevent its being interpreted as a shell meta
character.

The following command sets the value of the parameter
ip_forwarding in the dual stack IP driver to zero. This dis-
ables IPv4 packet forwarding.

example% ndd -set /dev/ip ip_forwarding 0

Similarly, in order to disable IPv6 packet forwarding, the
value of parameter ip6_forwarding

example% ndd -set /dev/ip ip6_forwarding 0

To view the current IPv4 forwarding table, use the following
command:

SunOS 5.10 Last change: 8 Nov 1999 1

System Administration Commands ndd(1M)

example% ndd /dev/ip ipv4_ire_status

To view the current IPv6 forwarding table, use the following
command:

example% ndd /dev/ip ipv6_ire_status

ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:

____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Availability | SUNWcsu |
|_____________________________|_____________________________|

SEE ALSO
nca(1), ioctl(2), attributes(5), arp(7P), ip(7P), ip6(7P),
tcp(7P), udp(7P)

NOTES
The parameters supported by each driver may change from
release to release. Like programs that read /dev/kmem, user
programs or shell scripts that execute ndd should be
prepared for parameter names to change.

The ioctl() command that ndd uses to communicate with
drivers is likely to change in a future release. User pro-
grams should avoid making dependencies on it.

The meanings of many ndd parameters make sense only if you
understand how the driver is implemented.

SunOS 5.10 Last change: 8 Nov 1999 2

[ray.wurlod]

Thanks for that, it didn't reveal anything. What happens with

Code: Select all

ndd /dev/tcp \? 

[ArndW]

You get

? (read only)
tcp_time_wait_interval (read and write)
tcp_conn_req_max_q (read and write)
tcp_conn_req_max_q0 (read and write)
tcp_conn_req_min (read and write)
tcp_conn_grace_period (read and write)
tcp_cwnd_max (read and write)
tcp_debug (read and write)
tcp_smallest_nonpriv_port (read and write)
tcp_ip_abort_cinterval (read and write)
tcp_ip_abort_linterval (read and write)
tcp_ip_abort_interval (read and write)
tcp_ip_notify_cinterval (read and write)
tcp_ip_notify_interval (read and write)
tcp_ipv4_ttl (read and write)
tcp_keepalive_interval (read and write)
tcp_maxpsz_multiplier (read and write)
tcp_mss_def_ipv4 (read and write)
tcp_mss_max_ipv4 (read and write)
tcp_mss_min (read and write)
tcp_naglim_def (read and write)
tcp_rexmit_interval_initial (read and write)
tcp_rexmit_interval_max (read and write)
tcp_rexmit_interval_min (read and write)
tcp_deferred_ack_interval (read and write)
tcp_snd_lowat_fraction (read and write)
tcp_sth_rcv_hiwat (read and write)
tcp_sth_rcv_lowat (read and write)
tcp_dupack_fast_retransmit (read and write)
tcp_ignore_path_mtu (read and write)
tcp_smallest_anon_port (read and write)
tcp_largest_anon_port (read and write)
tcp_xmit_hiwat (read and write)
tcp_xmit_lowat (read and write)
tcp_recv_hiwat (read and write)
tcp_recv_hiwat_minmss (read and write)
tcp_fin_wait_2_flush_interval (read and write)
tcp_co_min (read and write)
tcp_max_buf (read and write)
tcp_strong_iss (read and write)
tcp_rtt_updates (read and write)
tcp_wscale_always (read and write)
tcp_tstamp_always (read and write)
tcp_tstamp_if_wscale (read and write)
tcp_rexmit_interval_extra (read and write)
tcp_deferred_acks_max (read and write)
tcp_slow_start_after_idle (read and write)
tcp_slow_start_initial (read and write)
tcp_co_timer_interval (read and write)
tcp_sack_permitted (read and write)
tcp_trace (read and write)
tcp_compression_enabled (read and write)
tcp_ipv6_hoplimit (read and write)
tcp_mss_def_ipv6 (read and write)
tcp_mss_max_ipv6 (read and write)
tcp_rev_src_routes (read and write)
tcp_local_dack_interval (read and write)
tcp_ndd_get_info_interval (read and write)
tcp_local_dacks_max (read and write)
tcp_ecn_permitted (read and write)
tcp_rst_sent_rate_enabled (read and write)
tcp_rst_sent_rate (read and write)
tcp_push_timer_interval (read and write)
tcp_use_smss_as_mss_opt (read and write)
tcp_wroff_xtra (read and write)
tcp_mdt_hdr_head_min (read and write)
tcp_mdt_hdr_tail_min (read and write)
tcp_mdt_max_pbufs (read and write)
tcp_extra_priv_ports (read only)
tcp_extra_priv_ports_add (write only)
tcp_extra_priv_ports_del (write only)
tcp_status (read only)
tcp_bind_hash (read only)
tcp_listen_hash (read only)
tcp_conn_hash (read only)
tcp_acceptor_hash (read only)
tcp_host_param (read and write)
tcp_host_param_ipv6 (read and write)
tcp_1948_phrase (write only)
tcp_reserved_port_list (read only)
tcp_close_wait_interval(obsoleted- use tcp_time_wait_interval) (no read or write)

[ray.wurlod]

OK, I stand corrected (though wondering about why I thought it was microseconds). Have to wait till next time I'm on a Solaris system to investigate.

Just out of curiosity (again!) is the default on your system 4,000,000 ?