How to debug daemons under the Solaris SMF control [ID 1007672.1]

Applies to:
Solaris SPARC Operating System - Version: 10 3/05 and later   [Release: 10.0 and later ]
All Platforms
Goal
Solaris 10 Operating System introduced the Service Management Facility (SMF), which manages system services such as daemons. Debugging problems traditionally involves killing and restarting those daemons with debugging options. Under SMF the daemons will be immediately restarted so additional steps need to be taken.
Solution

There are three options:

1. Disable the service and start the daemon(s) manually

2. Modify the service method

3. Modify the service manifest

Before proceeding it is important that the reader familiarise themselves with the SMF, the smf(5) man page is the recommended starting point.

---------------------------------------------------------------------------

1. Disable the service and start the daemon(s) manually

This is the simplest option and is generally recommended. The only complication is debugging services that other services depend upon or services that themselves start multiple daemons.

Determining the dependencies on a service is outside the current scope of this document. For further information consult the svcs(1) man page and in particular the -D option.

If a service is disabled it could have undesirable consequences as SMF service state is persistent across boots. The use of the svcadm(1M) disable -t option is recommended. This ensures that the service is temporarily disabled and will be enabled on reboot.

The steps involved are:

a. The service is temporarily disabled with svcadm(1M)

b. The relevant daemons are restarted with the required options

c. Debug the problem

d. If still running, kill the relevant daemons

e. The service is enabled with svcadm(1M)

Example - keyserv

a. The service is temporarily disabled with svcadm(1M)

	# svcs keyserv
STATE STIME FMRI
online 16:21:12 svc:/network/rpc/keyserv:default
# svcadm disable -t keyserv
# svcs keyserv
STATE STIME FMRI
disabled 16:26:55 svc:/network/rpc/keyserv:default
# svcs -l keyserv
fmri svc:/network/rpc/keyserv:default
name RPC encryption key storage
enabled false (temporary)
state disabled
next_state none
state_time Thu May 17 16:26:55 2007
logfile /var/svc/log/network-rpc-keyserv:default.log
restarter svc:/system/svc/restarter:default
contract_id
dependency require_all/restart svc:/network/rpc/bind (online)
dependency require_all/restart svc:/system/identity:domain (online)
#

b. The relevant daemons are restarted with the required options

	# pgrep -lf keyserv
# keyserv -D 2>/var/tmp/keyserv.debug 1>&2 &
[1] 3072
# pgrep -lf keyserv
3072 keyserv -D
#

c. Debug the problem

	# tail -f /var/tmp/keyserv.debug
default disk cache size: 1MB
supported mechanisms:
alias disk cache size
===== ===============
dh192-0 0MB

d. If still running, kill the relevant daemons

	# pgrep -lf keyserv
3072 keyserv -D
# pkill -x keyserv
# pgrep -lf keyserv
[1] + Terminated keyserv -D 2>/var/tmp/keyserv.debug 1>&2 &
#

e. The service is enabled with svcadm(1M)

	# svcs keyserv
STATE STIME FMRI
disabled 16:26:55 svc:/network/rpc/keyserv:default
# svcadm enable keyserv
# svcs keyserv
STATE STIME FMRI
online 16:30:33 svc:/network/rpc/keyserv:default
#
---------------------------------------------------------------------------

2. Modify the service method

This is more complex but does resolve the problems related to dependencies and the services still being available after a reboot.

Most (but not all) services are started from scripts that are found in /lib/svc/method. Editing these scripts is not supported outside of explicit instructions to do so by Support in the course of an investigation.

The steps involved are:

a. The service is disabled with svcadm(1M)

b. The relevant method is edited

c. The service is enabled with svcadm(1M)

d. Debug the problem

e. The service is disabled with svcadm(1M)

f. The relevant method is restored

g. The service is enabled with svcadm(1M)

Example - the NIS+ cache manager

a. The service is disabled with svcadm(1M)

	# svcs nisplus
STATE STIME FMRI
online 16:37:12 svc:/network/rpc/nisplus:default
# svcadm disable nisplus
# svcs nisplus
STATE STIME FMRI
disabled 16:47:16 svc:/network/rpc/nisplus:default
#

b. The relevant method is edited

	# grep nis_cachemgr /lib/svc/method/nisplus
/usr/sbin/nis_cachemgr $cachemgr_flags || exit $?
# vi /lib/svc/method/nisplus
... the start options are changed, eg adding '-v'

c. The service is enabled with svcadm(1M)

	# svcs nisplus
STATE STIME FMRI
disabled 16:47:16 svc:/network/rpc/nisplus:default
# svcadm enable nisplus
# svcs nisplus
STATE STIME FMRI
online 16:49:57 svc:/network/rpc/nisplus:default
#

d. Debug the problem

	# pgrep -lf nis_cachemgr
647 /usr/sbin/nis_cachemgr -v
#

e. The service is disabled with svcadm(1M)

	# svcs nisplus
STATE STIME FMRI
online 16:49:57 svc:/network/rpc/nisplus:default
# svcadm disable nisplus
# svcs nisplus
STATE STIME FMRI
disabled 16:50:50 svc:/network/rpc/nisplus:default
#

f. The relevant method is edited

	# grep nis_cachemgr /lib/svc/method/nisplus
/usr/sbin/nis_cachemgr -v $cachemgr_flags || exit $?
# vi /lib/svc/method/nisplus
... the start options are restored, eg removing '-v'

g. The service is enabled with svcadm(1M)

	# svcs nisplus
STATE STIME FMRI
disabled 16:50:50 svc:/network/rpc/nisplus:default
# svcadm enable nisplus
# svcs nisplus
STATE STIME FMRI
online 16:52:13 svc:/network/rpc/nisplus:default
#
---------------------------------------------------------------------------

3. Modify the service manifest

This is more complex again and similarly does resolve the problems related to dependencies and the services still being available after a reboot.

This method could be used to, say, define an alternative service (eg for service foo, a service foo-debug). The original service is disabled, the debug service is then enabled. The problem is that any dependencies on the original service will not take account of the new service name. For this reason defining alternative services is not advised.

The manifests define the start methods and a manifest can be changed to use a different method. The method can be changed either directly with editprop inside svccfg(1M) or, again using svccfg(1M), the manifest can be exported, edited and imported again. Modification of the standard manifests is not supported outside of explicit instructions to do so by Support in the course of an investigation.

The steps involved are:

a. The service is disabled with svcadm(1M)

b. The manifest is edited (eg exported, edited, re-imported)

c. A new method is written

d. The service is enabled with svcadm(1M)

e. Debug the problem

f. The service is disabled with svcadm(1M)

g. The original manifest is restored

h. The service is enabled with svcadm(1M)

Example - keyserv

a. The service is disabled with svcadm(1M)

	# svcs keyserv
STATE STIME FMRI
online 16:43:44 svc:/network/rpc/keyserv:default
# svcadm disable keyserv
# svcs keyserv
STATE STIME FMRI
disabled 16:58:34 svc:/network/rpc/keyserv:default
#

b. The manifest is edited (eg exported, edited, re-imported)

	# svccfg
svc:> export keyserv > /var/tmp/keyserv.xml
svc:> exit
# cp /var/tmp/keyserv.xml /var/tmp/keyserv.xml.orig
# grep sbin/keyserv /var/tmp/keyserv.xml
<... exec='/usr/sbin/keyserv' ...>
# vi /var/tmp/keyserv.xml
... change the start method, eg /var/tmp/keyserv

# svccfg
svc:> delete keyserv
svc:> select *keyserv*
Pattern '*keyserv*' doesn't match any instances or services
svc:> import /var/tmp/keyserv.xml
svc:> select *keyserv*
svc:/network/rpc/keyserv> listprop
...
start/exec astring /var/tmp/keyserv
...
svc:/network/rpc/keyserv> exit
#

c. A new method is written

	We need to create the method, in this case, /var/tmp/keyserv:
#!/sbin/sh
#
/usr/sbin/keyserv -D 2>/var/tmp/keyserv.debug 1>&2 &
exit 0

d. The service is enabled with svcadm(1M)

	# svcs keyserv
STATE STIME FMRI
disabled 17:04:26 svc:/network/rpc/keyserv:default
# svcadm enable keyserv
# svcs keyserv
STATE STIME FMRI
online 17:05:51 svc:/network/rpc/keyserv:default
# pgrep -lf keyserv
688 /usr/sbin/keyserv -D
#

e. Debug the problem

	# tail -f /var/tmp/keyserv.debug
default disk cache size: 1MB
supported mechanisms:
alias disk cache size
===== ===============
dh192-0 0MB

f. The service is disabled with svcadm(1M)

	# svcs keyserv
STATE STIME FMRI
online 17:05:51 svc:/network/rpc/keyserv:default
# svcadm disable keyserv
# svcs keyserv
STATE STIME FMRI
disabled 17:07:25 svc:/network/rpc/keyserv:default
#

g. The original manifest is restored

	# svccfg
svc:> delete *keyserv*
svc:> select *keyserv*
Pattern '*keyserv*' doesn't match any instances or services
svc:> import /var/tmp/keyserv.xml.orig
svc:> select *keyserv*
svc:/network/rpc/keyserv> listprop
...
start/exec astring /usr/sbin/keyserv
...
#
NOTE: The original manifests in /var/svc/manifest can also be
used to restore the service.

h. The service is enabled with svcadm(1M)

	# svcs keyserv
STATE STIME FMRI
disabled 17:08:17 svc:/network/rpc/keyserv:default
# svcadm enable keyserv
# svcs keyserv
STATE STIME FMRI
online 17:09:22 svc:/network/rpc/keyserv:default
# pgrep -lf keyserv
705 /usr/sbin/keyserv
#
---------------------------------------------------------------------------

Product
Solaris 10 Operating System

转载于:https://www.cnblogs.com/cqubityj/archive/2013/05/07/3065037.html

以下是对提供的参考资料的总结,按照要求结构化多个要点分条输出: 4G/5G无线网络优化与网规案例分析: NSA站点下终端掉4G问题:部分用户反馈NSA终端频繁掉4G,主要因终端主动发起SCGfail导致。分析显示,在信号较好的环境下,终端可能因节能、过热保护等原因主动释放连接。解决方案建议终端侧进行分析处理,尝试关闭节电开关等。 RSSI算法识别天馈遮挡:通过计算RSSI平均值及差值识别天馈遮挡,差值大于3dB则认定有遮挡。不同设备分组规则不同,如64T和32T。此方法可有效帮助现场人员识别因环境变化引起的网络问题。 5G 160M组网小区CA不生效:某5G站点开启100M+60M CA功能后,测试发现UE无法正常使用CA功能。问题原因在于CA频点集标识配置错误,修正后测试正常。 5G网络优化与策略: CCE映射方式优化:针对诺基亚站点覆盖农村区域,通过优化CCE资源映射方式(交织、非交织),提升RRC连接建立成功率和无线接通率。非交织方式相比交织方式有显著提升。 5G AAU两扇区组网:与三扇区组网相比,AAU两扇区组网在RSRP、SINR、下载速率和上传速率上表现不同,需根据具体场景选择适合的组网方式。 5G语音解决方案:包括沿用4G语音解决方案、EPS Fallback方案和VoNR方案。不同方案适用于不同的5G组网策略,如NSA和SA,并影响语音连续性和网络覆盖。 4G网络优化与资源利用: 4G室分设备利旧:面对4G网络投资压减与资源需求矛盾,提出利旧多维度调优策略,包括资源整合、统筹调配既有资源,以满足新增需求和提质增效。 宏站RRU设备1托N射灯:针对5G深度覆盖需求,研究使用宏站AAU结合1托N射灯方案,快速便捷地开通5G站点,提升深度覆盖能力。 基站与流程管理: 爱立信LTE基站邻区添加流程:未提供具体内容,但通常涉及邻区规划、参数配置、测试验证等步骤,以确保基站间顺畅切换和覆盖连续性。 网络规划与策略: 新高铁跨海大桥覆盖方案试点:虽未提供详细内容,但可推测涉及高铁跨海大桥区域的4G/5G网络覆盖规划,需考虑信号穿透、移动性管理、网络容量等因素。 总结: 提供的参考资料涵盖了4G/5G无线网络优化、网规案例分析、网络优化策略、资源利用、基站管理等多个方面。 通过具体案例分析,展示了无线网络优化中的常见问题及解决方案,如NSA终端掉4G、RSSI识别天馈遮挡、CA不生效等。 强调了5G网络优化与策略的重要性,包括CCE映射方式优化、5G语音解决方案、AAU扇区组网选择等。 提出了4G网络优化与资源利用的策略,如室分设备利旧、宏站RRU设备1托N射灯等。 基站与流程管理方面,提到了爱立信LTE基站邻区添加流程,但未给出具体细节。 新高铁跨海大桥覆盖方案试点展示了特殊场景下的网络规划需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值