As part of our maintenance schedule, we reboot our systems every few months to test HACMP and etc... etc....
It looked like everything was normal but when we tried to bring up HACMP, we didn't see anything in the /etc/hacmp.out and we didn't see any processes associated with HACMP running.
So, I looked at "lssrc -a" to see if the subsystems associated with HACMP was running and this is part of what I saw:
atlmboxa/root :/>lssrc -a|more
Subsystem Group PID Status
qdaemon spooler inoperative
writesrv spooler inoperative
lpd spooler inoperative
clvmd inoperative
inetd tcpip inoperative
gated tcpip inoperative
named tcpip inoperative
.....
.......
...........
All of the subsystems show up as inoperative, starting them manually does not help, rebooting the system does not help.
Has anyone seen this behavior before? If so, what is causing it and how do we fix it.
Hi All,
After restarting the xntpd process for some reasons when i checked the status its showing inoprative eventhough xntpd process is running when i ps on it.
$ lssrc -s xntpd
Subsystem Group PID Status
xntpd tcpip ... (1 Reply)
I'm just wondering what the differences/relationships there are between processes, services, daemons and subsystems?
I keep coming across these terms but I can't find clear definitions/explanations of these terms.
:confused: (3 Replies)
CRM_STANDBY(8) [FIXME: manual] CRM_STANDBY(8)NAME
crm_standby - manipulate a node's standby attribute to determine whether resources can be run on this node
SYNOPSIS
crm_standby [-?|-V] -D -u|-U node -r resource
crm_standby [-?|-V] -G -u|-U node -r resource
crm_standby [-?|-V] -v string -u|-U node -r resource [-l string]
DESCRIPTION
The crm_standby command manipulates a node's standby attribute. Any node in standby mode is no longer eligible to host resources and any
resources that are there must be moved. Standby mode can be useful for performing maintenance tasks, such as kernel updates. Remove the
standby attribute from the node when it should become a fully active member of the cluster again.
By assigning a lifetime to the standby attribute, determine whether the standby setting should survive a reboot of the node (set lifetime
to forever) or should be reset with reboot (set lifetime to reboot). Alternatively, remove the standby attribute and bring the node back
from standby manually.
OPTIONS --help, -?
Print a help message.
--verbose, -V
Turn on debug information.
Note
Increase the level of verbosity by providing additional instances.
--quiet, -Q
When doing an attribute query using -G, print just the value to stdout. Use this option with -G.
--get-value, -G
Retrieve rather than set the preference.
--delete-attr, -D
Specify the attribute to delete.
--attr-value string, -v string
Specify the value to use. This option is ignored when used with -G.
--node-uuid node_uuid, -u node_uuid
Specify the UUID of the node to change.
--node-uname node_uname, -U node_uname
Specify the uname of the node to change.
--lifetime string, -l string
Determine how long this preference lasts. Possible values are reboot or forever.
Note
If a forever value exists, it is always used by the CRM instead of any reboot value.
EXAMPLES
Have a local node go to standby:
crm_standby -v true
Have a node (node1) go to standby:
crm_standby -v true -U node1
Query the standby status of a node:
crm_standby -G -U node1
Remove the standby property from a node:
crm_standby -D -U node1
Have a node go to standby for an indefinite period of time:
crm_standby -v true -l forever -U node1
Have a node go to standby until the next reboot of this node:
crm_standby -v true -l reboot -U node1
FILES
/var/lib/heartbeat/crm/cib.xml--the CIB (minus status section) on disk. Editing this file directly is strongly discouraged.
SEE ALSO
???, ???
AUTHOR
crm_standby was written by Andrew Beekhof.
[FIXME: source] 07/05/2010 CRM_STANDBY(8)