>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