RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 832056 - wdmd initscript should verify that /dev/watchdog exists
Summary: wdmd initscript should verify that /dev/watchdog exists
Keywords:
Status: CLOSED DUPLICATE of bug 832935
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sanlock
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: rc
: ---
Assignee: David Teigland
QA Contact: Yaniv Kaul
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-14 12:00 UTC by Rami Vaknin
Modified: 2014-07-01 11:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-26 21:10:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Rami Vaknin 2012-06-14 12:00:13 UTC 
Environment:
RHEL 6.3, sanlock-2.3-1.el6.x86_64

Scenario:
sanlock and wdmd services die right after startup, although they report that they started OK.
The reason is missing /dev/watchdog device which should be loaded by watchdog hardware or softdog module.

Unless sanlock is started explicitly without wdmd usage, it should look for a /dev/watchdog device during startup.


# /etc/init.d/sanlock restart
Sending stop signal sanlock:                               [FAILED]
Waiting for sanlock to stop:                               [  OK  ]
Starting sanlock:                                          [  OK  ]
# /etc/init.d/sanlock status
sanlock is stopped
#


# /etc/init.d/wdmd restart
Stopping wdmd:                                             [FAILED]
Starting wdmd:                                             [  OK  ]
# /etc/init.d/wdmd status
wdmd is stopped
#

From /var/log/messages:
Jun 14 14:43:34 localhost wdmd[15565]: wdmd started tests_built client
Jun 14 14:43:34 localhost wdmd[15565]: no /dev/watchdog, load a watchdog driver
Comment 2 Dafna Ron 2012-06-25 13:24:15 UTC 
moving to urgent since after install of si7 with vdsm vdsm-4.9.6-17.0.el6.x86_64
my vm's failed to run with:

Thread-1216::ERROR::2012-06-25 15:05:57,958::vm::604::vm.Vm::(_startUnderlyingVm) vmId=`3b80bb3c-8fad-4c48-aa5c-e5d26224bcfb`::The vm start process failed
Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 570, in _startUnderlyingVm
    self._run()
  File "/usr/share/vdsm/libvirtvm.py", line 1364, in _run
    self._connection.createXML(domxml, flags),
  File "/usr/lib/python2.6/site-packages/vdsm/libvirtconnection.py", line 82, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2490, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error Failed to open socket to sanlock daemon: No such file or directory


/var/log/sanlock.log will show the following when we try to start it: 

wdmd connect failed for watchdog handling
Comment 3 David Teigland 2012-06-25 15:49:31 UTC 
Can you include any wdmd messages from /var/log/messages?

Do things start properly if you 'modprobe softdog' yourself before wdmd and sanlock are started?
Comment 4 Dafna Ron 2012-06-25 15:52:21 UTC 
yes. 
after I ran modprobe softdog and restarted all services I was able to run the vms
but I would have to run it each time I reboot my host or vm's will fail to run.
Comment 5 David Teigland 2012-06-25 16:06:59 UTC 
In my test, 'service wdmd start' loads the softdog module and starts wdmd without a problem.  Do you have the latest sanlock package installed?
 sanlock-2.3-1.1.gitfee5d9c.el6_3.x86_64.rpm 

I wonder if /dev/watchdog already exists prior to starting wdmd?  That would cause init.d/wdmd to not load the softdog module.  Could you run the following and verify that /dev/wathdog doesn't exist, and that "Load the softdog..." message appears?

[root@bull-01 ~]# ls -l /dev/watchdog
ls: cannot access /dev/watchdog: No such file or directory
[root@bull-01 ~]# service wdmd start
Loading the softdog kernel module:                         [  OK  ]
Starting wdmd:                                             [  OK  ]
Comment 8 Dafna Ron 2012-06-26 08:45:52 UTC 
starting wdmd will not load softdog: 

[root@blond-vdsh ~]# ls -l /dev/watchdog
ls: cannot access /dev/watchdog: No such file or directory
[root@blond-vdsh ~]# service wdmd start
Starting wdmd:                                             [  OK  ]
[root@blond-vdsh ~]# service wdmd status
wdmd is stopped
[root@blond-vdsh ~]# ls -l /dev/watchdog
ls: cannot access /dev/watchdog: No such file or directory
[root@blond-vdsh ~]#
Comment 9 David Teigland 2012-06-26 15:31:59 UTC 
I see in the original description you're using sanlock-2.3-1.el6.x86_64.
You need to use the the latest build that Federico set up for you to test with before he left:  sanlock-2.3-1.1.gitfee5d9c.el6_3.x86_64
Comment 10 Rami Vaknin 2012-06-26 15:35:51 UTC 
The original description was mine, the reproduction made by Dafna Ron.

Dafna, could you please add the sanlock version you tested with?
Comment 11 Dafna Ron 2012-06-26 15:42:20 UTC 
[root@blond-vdsh ~]# rpm -qa |grep sanlock
sanlock-python-2.3-1.el6.x86_64
libvirt-lock-sanlock-0.9.10-21.el6.x86_64
sanlock-lib-2.3-1.el6.x86_64
sanlock-2.3-1.el6.x86_64
Comment 12 David Teigland 2012-07-26 21:10:28 UTC 

*** This bug has been marked as a duplicate of bug 832935 ***
Note You need to log in before you can comment on or make changes to this bug.