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 of over 48,000 articles and solutions.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
