sanlock issues

If you are trying to run sanlock on fedora and you get this error:

Sep 23 11:26:56 dhcp-XX-XX.tlv.redhat.com sanlock[7083]: 2012-09-23 11:26:56+0200 37014
[7083]: wdmd connect failed for watchdog handling

You need to do this:

# unload softdog if it's running
rmmod softdog
# Check if there are residual watchdog files under /dev and remove them
rm /dev/watchdog*
# reload the softdog module
modprobe softdog
# make sure the file is named /dev/watchdog
mv /dev/watchdog? /dev/watchdog
# set the proper selinux context
restorecon /dev/watchdog
# restart wdmd
systemctl restart wdmd.service
# restart sanlock
systemctl restart sanlock.service
# Profit!
fortune

[Federico Simoncelli]

----- Original Message -----
>  From: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt;
>  To: "vdsm-devel" <vdsm-devel(a)fedorahosted.org&gt;
>  Cc: "ybronhei" <ybronhei(a)redhat.com&gt;, "Federico Simoncelli"
> <fsimonce(a)redhat.com&gt;, "Barak Azulay"
>  <bazulay(a)redhat.com&gt;
>  Sent: Sunday, September 23, 2012 1:17:01 PM
>  Subject: sanlock issues
>  
>  If you are trying to run sanlock on fedora and you get this error:
>  
>  Sep 23 11:26:56 dhcp-XX-XX.tlv.redhat.com sanlock[7083]: 2012-09-23
>  11:26:56+0200 37014 [7083]: wdmd connect failed for watchdog
>  handling
>  
>  You need to do this:
>  
>  # unload softdog if it's running
>  rmmod softdog
>  # Check if there are residual watchdog files under /dev and remove
>  them
>  rm /dev/watchdog*
>  # reload the softdog module
>  modprobe softdog
>  # make sure the file is named /dev/watchdog
>  mv /dev/watchdog? /dev/watchdog
>  # set the proper selinux context
>  restorecon /dev/watchdog
>  # restart wdmd
>  systemctl restart wdmd.service
>  # restart sanlock
>  systemctl restart sanlock.service
>  # Profit!
>  fortune 
There are several things involved here.

Were multiple watchdog modules loaded? Why? Is the hardware watchdog loaded
after sanlock (which itself loads the softdog)? Is sanlock loading the softdog
even if there in an hardware watchdog present?

It might also be an udev issue with the device naming. You shouldn't need to
relabel the device (another udev issue?).

I doubt that this workaround would survive a reboot (did you check?)
BTW. fedora 17 or 18?

-- 
Federico

[Ryan Harper]

* Saggi Mizrahi <smizrahi(a)redhat.com&gt; [2012-09-23 06:17]:
>  If you are trying to run sanlock on fedora and you get this error:
>  
>  Sep 23 11:26:56 dhcp-XX-XX.tlv.redhat.com sanlock[7083]: 2012-09-23 11:26:56+0200 37014
> [7083]: wdmd connect failed for watchdog handling
>  
>  You need to do this:
>  
>  # unload softdog if it's running
>  rmmod softdog
>  # Check if there are residual watchdog files under /dev and remove them 
I'd be interested in seeing a file listing:

ls -al /dev/watchdog*

and comparing that to what you have after you do all of the cleanup
below.

I know the major change from F16 and f17 w.r.t /dev/ is that f17 kernels
are using udevtmpfs which is responsible only for creation of files in
/dev; it punts the acls and permissions to udev and systemd.

In f16, udev (< release 182) would force the creation of nodes in /dev
which helped if the wrong misc device was created by other programs or
scripts.  Now, with udevtmpfs, if a file is already present in /dev,
udevtmpfs won't update/change the file.

>  rm /dev/watchdog*
>  # reload the softdog module
>  modprobe softdog
>  # make sure the file is named /dev/watchdog
>  mv /dev/watchdog? /dev/watchdog
>  # set the proper selinux context
>  restorecon /dev/watchdog
>  # restart wdmd
>  systemctl restart wdmd.service
>  # restart sanlock
>  systemctl restart sanlock.service
>  # Profit!
>  fortune
>  _______________________________________________
>  vdsm-devel mailing list
>  vdsm-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel 
-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com