Stop hourly scsi_reserve errors in messages file

Solution Unverified - Updated -

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.

Current Customers and Partners

Log in for full access

Log In
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.