Stop hourly scsi_reserve errors in messages file
Issue
Even when the scsi_reserve service is off, the following error message is logged at regular intervals in /var/log/messages:
-
scsi_reserve: [error] cluster not configured for scsi reservations
Environment
- Red Hat Enterprise Linux 5 (With Cluster or Cluster storage Add On)
- Red Hat Enterprise Linux 6 (With High Availability or Resilient Storage Add On)
- chkconfig shows scsi_reserve off.
Diagnostic Steps
- It's strange that these messages are occurring once every hour, especially with scsi_reserve chkconfig'd off.
- This message is only printed when the script /etc/init.d/scsi_reserve is run, so obviously something is calling it.
- Add a simple debug line to scsi_reserve at the top that prints the parent information:
-
logger "scsi_reserve executed by $(ps -p $PPID -o comm=)" - Once the error message was generated, logger let us know that the tripwire application was checking the status of scsi_reserve.
-
If you look at the top of the scsi_reserve script, there's a case statement that just drops through and ends up in a chunk of code that logs the error seen. If you place an echo in the status routine pointed out and then do # scsi_reserve status you will see that it never reaches the status routine:
- Here is the status part of the script:
(status) error=0 count=0 for dev in $pv_devices do if sg_persist -n -d $dev -i -k | grep -qiE "$key" ; then devices[${#devices[@]}]=$dev fi done if [ -z "$devices" ] ; then echo "No registered devices found." else echo "Found ${#devices[@]} registered device(s):" for i in "${devices[@]}" do echo $i done fi ;; # end of status - It appears that the 'status' doesn't give the status of the service (running or stopped), it gives the status of the scsi reservations on the devices.
- This can be confirmed against a cluster that has scsi fencing configured.
- Iptables works the same way. 'service iptable status' doesn't say 'running'... it spits out current iptables rules. If it is stopped it says 'stopped'. It appears the scsi_reserve script has the logic for this.
Root Cause
- Found out that the cause of the messages is the logic of the script and for this particular environment also tripwire. Tripwire does a /sbin/service --status-all as part of it's hourly processing.
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.
