>Steve Peng wrote:
>Richard L. Hamilton wrote:
>> Fresh install of b66 on a Sun Blade 2000 (UltraSPARC III).
>> Disable/enable, still doesn't start.
>> Starts fine by hand, or by running the method script by hand.
>> No log for the service in /var/svc/log; nothing relevant in the
>> log for the network-inetd restarter, either.  Only thing in /var/adm/messages
>> is lines like:
>>
>> Jun 18 17:10:45 paradox inetd[369]: [ID 702911 daemon.warning] inetd_offline 
method for instance svc:/network/rpc/cde-ttdbserver:tcp is unspecified.  Taking 
default action: kill.
>>   
>Basically every time an inetd managed service is disabled/restarted, the 
>service's inetd_offline method will be invoked and in the
>absence of this method, the default action (:kill_proc) will be taken.  
>One thing you can do is to turn on inetd debug mode by
>touching /var/tmp/inetd.log file and reboot the system.  This way we can 
>tell why rpc.ttdbserverd is not running in the first place.

Actually, didn't need to reboot, just restart svc:/network/inetd:default
(since I was the only user, it's not as if it would bother anyone).  One
of the joys of SMF, at least when it works...

Not that the log really told me anything I could make heads or tails of.

But I did notice something with rpcinfo:

# rpcinfo -s|awk 'NR==1||$0~/100083/'
   program version(s) netid(s)                         service     owner
    100083  1         ticotsord                        ttdbserverd superuser


(I'd given names in my NIS rpc map to as many rpc program numbers as I
knew what they were and didn't already have a name, so that may look a bit
different from what you might see.)

Likewise, I see

# inetadm -l svc:/network/rpc/cde-ttdbserver:tcp
SCOPE    NAME=VALUE
         name="100083"
         endpoint_type="tli"
         proto="ticotsord"
         isrpc=TRUE
         rpc_low_version=1
         rpc_high_version=1
         wait=TRUE
         exec="/lib/svc/method/rpc-ttdbserverd"
         user="root"
default  bind_addr=""
default  bind_fail_max=-1
default  bind_fail_interval=-1
default  max_con_rate=-1
default  max_copies=-1
default  con_rate_offline=-1
default  failrate_cnt=40
default  failrate_interval=60
default  inherit_env=TRUE
default  tcp_trace=FALSE
default  tcp_wrappers=FALSE


But I don't see anything in /var/svc/manifest/network/rpc/cde-ttdbserverd.xml
that explains why inetd is listening on netid ticotsord rather than tcp.

I could do something like

rpcinfo -T ticotsord `uname -n` 100083 1

which would get a positive response and cause it to be started.

Or I could do

inetadm -m svc:/network/rpc/cde-ttdbserver:tcp proto=tcp

and it would then be registered on tcp and tcp6 and start on demand (although
_not_ be registered on ticotsord).

Typical ToolTalk apps like ttcp don't seem to talk ticotsord, but are
happy to talk tcp; that is, until I had rpc.ttdbserverd running, ttcp
would get one of TT_ERR_DBAVAIL or TT_ERR_DBEXIST (I forget which now).

Not sure what the story is here; it may not be an SMF issue per se except
that I wonder where that proto="ticotsord" came from.
 
 
This message posted from opensolaris.org

Reply via email to