This is a draft document that was built and uploaded automatically. It may document beta software and be incomplete or even incorrect. Use this document at your own risk.

Jump to content
Introduction to the Hawk Web Interface
SUSE Linux Enterprise High Availability 16.0

Introduction to the Hawk Web Interface

Publication Date: 25 Sep 2026

Hawk is a Web-based graphical interface for configuring and managing SUSE Linux Enterprise High Availability clusters. You can use Hawk on any Linux or non-Linux machine with a Web browser and network access to the cluster nodes. This article introduces some of Hawk's basic concepts and usage.

Requirements:

  • Cluster nodes with the hawk2 package installed and the hawk and hawk-backend services enabled

  • A client machine with network access to the cluster nodes and a Web browser with JavaScript and cookies enabled

1 What is Hawk?

Hawk (HA Web Konsole) is a Web-based graphical interface for configuring and managing SUSE Linux Enterprise High Availability clusters. You can use Hawk on any Linux or non-Linux machine (the client machine) with a Web browser and network access to the cluster nodes.

You can access Hawk using the IP address of any node in the cluster that has the Hawk service running. Alternatively, you can create a floating, virtual IP address so that you can access Hawk with a consistent address. If you install the cluster with crm cluster init, the setup script can create the virtual IP address for you. Hawk uses the HTTPS protocol and port 7630.

Most screens in Hawk refresh in near real time, so cluster configuration changes are visible almost immediately.

1.1 Requirements

Client requirements
  • To connect to Hawk, the client machine must have network access to the cluster nodes.

  • To use Hawk, the client machine must have a graphical Web browser with JavaScript and cookies enabled.

Cluster node requirements
  • The hawk2 package must be installed on the node that you want to connect to. This is a recommended package in the ha_sles pattern, so it is typically installed on all nodes as part of the cluster installation.

  • The hawk and hawk-backend services must be started on the node that you want to connect to. If you installed the cluster with crm cluster init, these services are already enabled.

  • Hawk users must be members of the haclient group. If you installed the cluster with crm cluster init, the user hacluster is created by default. You can also create a new user in the haclient group.

  • Hawk users must have secure passwords. If you installed the cluster with crm cluster init, a default password is set for the hacluster user. Before starting Hawk, change the default password to a secure password.

  • For operations that use SSH, hacluster uses passwordless SSH authentication for communication between the nodes. If you added nodes to the cluster with crm cluster join, the SSH keys are already configured.

  • By default, Hawk generates and presents a self-signed certificate. We recommend replacing the generated certificate with your own certificate, or a certificate that was signed by an official Certificate Authority.

1.2 Top-level row

Hawk's top-level row shows the following options:

This image shows the Hawk Status screen, with the top-level row highlighted by a red box.
Figure 1: The Hawk top-level row
View Cluster Details

View details such as the cluster's status, which node is the Designated Coordinator, and the Pacemaker version, for example. Certain items are underlined, which means you can hover the cursor over them for more information.

Batch

Switch to batch mode. This allows you to simulate and stage changes and to apply them as a single transaction.

USERNAME

Set preferences for Hawk, such as the language for the Web interface, or whether to display a warning if fencing is disabled.

Help

Access the SUSE Linux Enterprise High Availability documentation, read the release notes or report a bug.

Logout

Log out of Hawk.

1.3 Left navigation bar

Hawk's left navigation bar shows the following options:

This image shows the Hawk Status screen, with the left navigation bar highlighted by a red box.
Figure 2: The Hawk left navigation bar
Monitoring
  • Status: Displays the current cluster status at a glance.

  • Dashboard: Allows you to monitor multiple clusters.

Troubleshooting
  • History: Opens the History Explorer, from which you can generate cluster reports.

  • Command Log: Lists the crm commands recently run by Hawk.

Configuration
  • Add Resource: Opens the resource configuration screen.

  • Add Constraint: Opens the constraint configuration screen.

  • Wizards: Allows you to select from several wizards that guide you through the creation of resources for a certain workload, for example, a DRBD block device.

  • Edit Configuration: Allows you to edit resources, constraints, node names and attributes, tags, alerts, and fencing topologies.

  • Cluster Configuration: Allows you to modify global cluster options and defaults.

  • Access Control › Roles: Allows you to create roles (sets of rules describing access rights to the CIB) for access control lists (ACLs).

  • Access Control › Targets: Allows you to create ACL targets (users) and assign roles to them.

2 Replacing Hawk's self-signed certificate

By default, Hawk generates and presents a self-signed certificate. We recommend replacing the generated certificate with your own certificate, or a certificate that was signed by an official Certificate Authority.

Hawk supports wild card certificates. A wild card certificate is a public key certificate that is valid for multiple sub-domains. For example, a wild card certificate for *.example.com is valid for www.example.com, login.example.com, etc.

Perform this procedure on every node that the Hawk service is running on:

  1. Replace /etc/hawk/hawk.key with the new private key.

  2. Replace /etc/hawk/hawk.pem with the new certificate for Hawk to present.

  3. Change ownership of the files to root:haclient and make the files accessible to the group:

    > sudo chown root:haclient /etc/hawk/hawk.key /etc/hawk/hawk.pem
    > sudo chmod 640 /etc/hawk/hawk.key /etc/hawk/hawk.pem
  4. Restart the Hawk services to reload the new certificate:

    > sudo systemctl restart hawk-backend hawk

3 Logging in to Hawk

Hawk allows you to manage a High Availability cluster using a graphical Web browser. You can also configure a floating, virtual IP address that allows clients to connect to Hawk no matter which node the Hawk service is running on.

By default, the hacluster user has read/write permissions for cluster configuration tasks. You can also use access control lists (ACLs) to fine-tune access permissions for other users. If ACLs are enabled, the available functions in Hawk depend on the user's role and access permissions. However, the History Explorer can only be used by the user hacluster.

Requirements
  • The client machine must be able to connect to the cluster nodes.

  • The client machine must have a graphical Web browser with JavaScript and cookies enabled.

This procedure uses the default hacluster user.

  1. Open a Web browser and go to https://HAWKSERVER:7630/, replacing HAWKSERVER with the IP address or host name of a cluster node, or the Hawk virtual IP address if one is configured.

    Note
    Note: Certificate warning

    If a certificate warning appears when you access the URL for the first time, a self-signed certificate is in use. To verify the certificate, ask your cluster operator for the certificate details. To proceed anyway, you can add an exception in the browser to bypass the warning.

  2. On the Hawk login screen, enter the Username and Password of the hacluster user.

  3. Click Log In. Hawk shows the Status screen by default.

The Status screen shows one configured resource: the virtual IP address admin-ip, running on a node called alice.
Figure 3: The Hawk Status screen

4 Hawk's Status screen

After you log in to Hawk, the Status screen is displayed by default.

This example of the Status screen shows an Error stating that fencing is disabled. In the list of resources, one is in maintenance mode, two are running, and one is stopped.
Figure 4: The Hawk status screen with more information

An icon in the upper-left corner shows the cluster status at a glance. Further details are shown in the following sections:

Errors

Cluster configuration errors are shown at the top of the page. You can click an error to automatically generate a report in the History Explorer.

Resources

The Resources tab shows the following information about the cluster resources:

  • Plus icon: Click this icon to show the child resources in groups or clones.

  • Status: An icon showing the resource's status, such as started, stopped or maintenance mode.

  • Name: The resource's ID.

  • Location: Which node the resource is currently running on.

  • Type: The specific resource agent.

  • Operations: A menu of actions that you can take on the resource, such as stopping, migrating, editing or switching to maintenance mode.

Nodes

The Nodes tab shows the following information about the cluster nodes:

  • Status: An icon showing the node's status, such as online, offline, or Designated Coordinator.

  • Name: The node's ID.

  • Maintenance: A toggle that switches maintenance mode on or off.

  • Standby: A toggle that switches standby mode on or off.

  • Operations: A menu of actions that you can take on the resource, such as viewing recent events, editing or fencing.

Tags

If you create a resource tag, it appears as an additional tab next to the Nodes tab. The tab shows the resources included in the tag and has the same columns as the Resources tab. Tag tabs also include an extra Operations drop-down menu that allows you to start or stop all the child resources at once.

5 Hawk's Dashboard screen

You can use the Dashboard screen to monitor multiple clusters. The clusters must all be running the same version of SUSE Linux Enterprise High Availability.

This example of the Dashboard screen shows tabs for two clusters, hacluster and hacluster2. The tab for hacluster shows three nodes, alice, bob and charlie, and four resources with green, red or white icons to indicate where (or if) the resources are running.
Figure 5: The Hawk dashboard screen

The Dashboard screen has the following functions:

Main dashboard

The main dashboard view shows the resources and nodes in the current cluster. For more information about the icons used in this view, click Legend. To search for a resource, use the Search text box. To only show specific nodes, click the filter icon and select a filtering option.

Add a cluster dashboard

To add a dashboard for another cluster, click Add Cluster and enter the cluster details. Hawk displays a second tab for the newly added cluster.

Tip
Tip: Connection error

If you are prompted to connect to this cluster by entering a password, you might not have replaced the self-signed certificate yet. In that case, even after you enter the password, the connection fails with the following message: Error connecting to server. Retrying every 5 seconds...

To resolve this issue, replace the self-signed certificate. Alternatively, log in to Hawk on the new cluster's nodes and either verify the self-signed certificate or add an exception in the browser to bypass the warning.

Switch to another cluster

To view more details for a cluster or to manage it, switch to the cluster's tab and click the chain icon. Hawk opens the Status view for this cluster in a new browser window or tab.

Remove a cluster dashboard

To remove a cluster from the dashboard, click the x icon on the right-hand side of the cluster's details. You can only remove additional clusters, not the main cluster.

6 Using batch mode

Hawk's batch mode allows you to stage configuration changes and apply them all as a single transaction, instead of having each change take effect immediately. This can be useful when configuring resources that are dependent on one another and require constraints.

Batch mode also includes a cluster simulator, which shows the expected outcome of each change without affecting the live cluster. For example, if you stop a resource while in batch mode, the user interface shows the resource as stopped, but in the live cluster the resource is still running.

You can also inject cluster events, such as node changes and resource operations, to explore potential failure scenarios. These changes are only simulations, and won't be applied to the live cluster along with the configuration changes.

Important
Important: Using configuration wizards in batch mode

Certain wizards include actions beyond cluster configuration, such as installing packages. When using those wizards in batch mode, any changes that go beyond cluster configuration would be applied to the live system immediately.

Therefore, wizards that require root permission can't be used while in batch mode.

  1. In a Web browser, go to https://HAWKSERVER:7630/ and log in.

  2. In the top-level row, click Batch.

    An additional bar appears below the top-level row to indicate that batch mode is active. This bar also includes the options to show, discard or apply your changes.

    At the top of the screen there is an orange banner that says “Batch mode active”. The right side of the banner has three options: Show, Discard and Apply.
    Figure 6: Hawk batch mode bar
  3. While batch mode is active, perform any changes to your cluster, like adding or editing resources and constraints, or editing the cluster configuration. The changes will be simulated but are not applied to the live cluster yet.

  4. To view details of your changes, select Show from the batch mode bar.

    The Batch Mode window opens and shows the difference between the live cluster and the simulated changes in crmsh syntax. Lines starting with a - character represent the current state, whereas lines starting with + show the proposed state.

    This example of the “Batch Mode” window shows that the user has changed the state of a resource clone from Started to Stopped. The top of the window also has two additional options: Simulator and Inject.
    Figure 7: Hawk Batch Mode window
  5. (Optional) To test potential failures or to see how the cluster behaves in a specific scenario, you can simulate node changes and resource operations:

    • Simulate a node failure or status change:

      1. Click Inject › Node Event.

      2. Select a Node and the node State to simulate.

      3. Click OK.

    • Simulate a resource operation:

      1. Click Inject › Resource Event.

      2. Select a Resource and the Operation to simulate.

      3. If necessary, define an Interval.

      4. Select the Node on which to run the operation.

      5. Select the operation Result to simulate.

      6. Click OK.

    The Batch Mode window shows a new line per injected event. Any event listed here is simulated immediately and is reflected on the Status screen.

    To remove an injected event, click the x icon next to it. Hawk updates the Status screen accordingly.

    This example of the “Batch Mode” window shows that the user has changed the state of a resource clone from Started to Stopped. The user has also injected a node event and a resource event.
    Figure 8: Hawk Batch Mode window with injected events
  6. (Optional) To view more details about the changes, click Simulator and choose one of the following:

    • Summary: Shows a detailed summary.

    • CIB (in): Shows the initial CIB state.

    • CIB (out): Shows what the CIB would look like after the transition.

    • Transition Graph: Shows a graphical representation of the transition.

    • Transition: Shows an XML representation of the transition.

  7. After reviewing your changes, click Close to exit the Batch Mode window.

  8. Choose whether to keep your changes or discard them:

    • To keep your changes, click Apply in the batch mode bar. The Apply Configuration window opens and shows a list of the changes. Only configuration changes are applied; injected events are not. Click Apply to confirm.

    • To discard your changes, click Discard in the batch mode bar, then click OK to confirm.

    Both options deactivate batch mode and take you back to normal mode.

7 Using the configuration wizards

The Hawk Wizards help you configure resources, from simple resources like a virtual IP address to complex configurations like a DRBD block device or an Apache Web server. The wizard guides you through the configuration steps and provides information about the parameters you need to enter.

  1. In a Web browser, go to https://HAWKSERVER:7630/ and log in.

  2. From the left navigation bar, select Configuration › Wizards.

  3. Select the wizard you want to use. You can expand the different categories by clicking the down arrow icons.

  4. Follow the instructions on the screen. Hawk shows a description for each parameter.

  5. If the wizard has more than one step, click Next to go to the next step.

  6. After the last step, click Verify. Hawk shows a list of the actions it will perform and what the configuration will look like.

  7. Click Apply. Depending on the configuration, you might be prompted for the root password.

    The list of steps turns green if the configuration was applied successfully.

This example shows the first page of the Apache Web server configuration wizard. It shows a drop-down list to specify whether to install Apache, and a field to enter an ID for the Apache cluster resource. There is also an option to add Advanced configuration.
Figure 9: Example: Hawk wizard for configuring an Apache web server

HA glossary

ACL (access control list)

Access control lists can be used to limit or fine-tune a user's access to the CIB. An ACL consists of an ordered set of access rules. Each rule allows or denies read or write access to a part of the CIB. Rules can be combined into specific roles, and users can be assigned to a role that matches their tasks.

active/active, active/passive

How resources run on the nodes. Active/passive means that resources only run on the active node, but can move to the passive node if the active node fails. Active/active means that all nodes are active at once, and resources can run on (and move to) any node in the cluster.

arbitrator

An arbitrator is a machine running outside the cluster to provide an additional instance for cluster calculations. For example, QNetd provides a vote to help QDevice participate in quorum decisions.

CIB (cluster information base)

An XML representation of the whole cluster configuration and status (cluster options, nodes, resources, constraints, etc.). The CIB manager (pacemaker-based) keeps the CIB synchronized across the cluster nodes and handles requests to modify it.

clone

In the context of a cluster resource, a clone is a resource that can be active on multiple nodes. Any resource can be cloned if its resource agent supports it.

cluster

A high-availability cluster is a group of servers (physical or virtual) designed primarily to secure the highest possible availability of data, applications and services. Not to be confused with a high-performance cluster, which shares the application load to achieve faster results.

Cluster LVM (Cluster logical volume manager)

The term Cluster LVM indicates that LVM is being used in a cluster environment. This requires configuration adjustments to protect the LVM metadata on shared storage.

cluster offline upgrade

If a new product version includes major changes that are backward incompatible, the cluster requires a cluster offline upgrade. You must stop the cluster services on all nodes and upgrade the whole cluster before bringing the nodes back online.

For minor version upgrades, see cluster rolling upgrade.

cluster partition

A cluster partition occurs when communication fails between one or more nodes and the rest of the cluster. The nodes are split into partitions but are still active. They can only communicate with nodes in the same partition and are unaware of the separated nodes. This is known as a split brain scenario.

cluster rolling upgrade

In a cluster rolling upgrade, one cluster node at a time is upgraded while the rest of the cluster is still running. Stop the cluster services on a node, upgrade it, then bring it back online to join the cluster. Continue one by one until all cluster nodes are upgraded.

For major version upgrades, see cluster offline upgrade.

cluster services

The services that run the cluster. Typically this refers to Pacemaker and Corosync, but might also include SBD and QDevice if those services are used.

cluster stack

The ensemble of software technologies and components that make up a cluster.

colocation constraint

A type of resource constraint that specifies which resources can or cannot run together on a node.

concurrency violation

A resource that should be running on only one node in the cluster is running on several nodes.

Corosync

Corosync provides reliable messaging, membership and quorum information about the cluster. This is handled by the Corosync Cluster Engine, a group communication system.

CRM (cluster resource manager)

The management entity responsible for coordinating all non-local interactions in a High Availability cluster. SUSE Linux Enterprise High Availability uses Pacemaker as the CRM. It interacts with several components: local executors on its own node and on the other nodes, non-local CRMs, administrative commands, the fencing functionality, and the membership layer.

crmsh (CRM Shell)

The command-line utility crmsh manages the cluster, nodes and resources.

Csync2

A synchronization tool for replicating configuration files across all nodes in the cluster.

DC (designated coordinator)

The pacemaker-controld daemon is the cluster controller, which coordinates all actions. This daemon has an instance on each cluster node, but only one instance is elected to act as the DC. The DC is elected when the cluster services start, or if the current DC fails or leaves the cluster. The DC decides whether a cluster-wide change must be performed, such as fencing a node or moving resources.

disaster

An unexpected interruption of critical infrastructure caused by nature, humans, hardware failure, or software bugs.

disaster recovery

The process by which a function is restored to the normal, steady state after a disaster.

Disaster Recovery Plan

A strategy to recover from a disaster with the minimum impact on IT infrastructure.

DLM (Distributed Lock Manager)

DLM coordinates accesses to shared resources in a cluster, for example, managing file locking in clustered file systems to increase performance and availability.

DRBD

DRBD® is a block device designed for building High Availability clusters. It replicates data on a primary device to secondary devices in a way that ensures all copies of the data remain identical.

existing cluster

The term existing cluster is used to refer to any cluster that consists of at least one node. An existing cluster has a basic Corosync configuration that defines the communication channels, but does not necessarily have resource configuration yet.

failover

Occurs when a resource or node fails on one machine and the affected resources move to another node.

failover domain

A named subset of cluster nodes that are eligible to run a resource if a node fails.

fencing

Prevents access to a shared resource by isolated or failing cluster members. There are two classes of fencing: resource-level fencing and node-level fencing. Resource-level fencing ensures exclusive access to a resource. Node-level fencing prevents a failed node from accessing shared resources and prevents resources from running on a node with an uncertain status. This is usually done by resetting or powering off the node.

GFS2

Global File System 2 (GFS2) is a shared disk file system for Linux computer clusters. GFS2 allows all nodes to have direct concurrent access to the same shared block storage. GFS2 has no disconnected operating mode, and no client or server roles. All nodes in a GFS2 cluster function as peers. GFS2 supports up to 32 cluster nodes. Using GFS2 in a cluster requires hardware to allow access to the shared storage, and a lock manager to control access to the storage.

group

Resource groups contain multiple resources that need to be located together, started sequentially and stopped in the reverse order.

Hawk (HA Web Konsole)

A user-friendly Web-based interface for monitoring and administering a High Availability cluster from Linux or non-Linux machines. Hawk can be accessed from any machine that can connect to the cluster nodes, using a graphical Web browser.

heuristics

QDevice supports using a set of commands (heuristics) that run locally on start-up of cluster services, cluster membership change, successful connection to the QNetd server, or optionally at regular times. The result is used in calculations to determine which partition should have quorum.

knet (kronosnet)

A network abstraction layer supporting redundancy, security, fault tolerance, and fast fail-over of network links. In SUSE Linux Enterprise High Availability 16, knet is the default transport protocol for the Corosync communication channels.

local cluster

A single cluster in one location (for example, all nodes are located in one data center). Network latency is minimal. Storage is typically accessed synchronously by all nodes.

local executor

The local executor is located between Pacemaker and the resources on each node. Through the pacemaker-execd daemon, Pacemaker can start, stop and monitor resources.

location

In the context of a whole cluster, location can refer to the physical location of nodes (for example, all nodes might be located in the same data center). In the context of a location constraint, location refers to the nodes on which a resource can or cannot run.

location constraint

A type of resource constraint that defines the nodes on which a resource can or cannot run.

meta attribute

Parameters that tell the CRM (cluster resource manager) how to treat a specific resource. For example, you might define a resource's priority or target role.

metro cluster

A single cluster that can stretch over multiple buildings or data centers, with all sites connected by Fibre Channel. Network latency is usually low. Storage is frequently replicated using mirroring or synchronous replication.

network device bonding

Network device bonding combines two or more network interfaces into a single bonded device to increase bandwidth and/or provide redundancy. When using Corosync, the bonded device is not managed by the cluster software. Therefore, the bonded device must be configured on every cluster node that might need to access it.

node

Any server (physical or virtual) that is a member of a cluster.

order constraint

A type of resource constraint that defines the sequence of actions.

Pacemaker

Pacemaker is the CRM (cluster resource manager) in SUSE Linux Enterprise High Availability, or the “brain” that reacts to events occurring in the cluster. Events might be nodes that join or leave the cluster, failure of resources, or scheduled activities such as maintenance, for example. The pacemakerd daemon launches and monitors all other related daemons.

parameters (instance attributes)

Parameters determine which instance of a service the resource controls.

primitive

A primitive resource is the most basic type of cluster resource.

promotable clone

Promotable clones are a special type of clone resource that can be promoted. Active instances of these resources are divided into two states: promoted and unpromoted (also known as “active and passive” or “primary and secondary”).

QDevice

QDevice and QNetd participate in quorum decisions. The corosync-qdevice daemon runs on each cluster node and communicates with QNetd to provide a configurable number of votes, allowing a cluster to sustain more node failures than the standard quorum rules allow.

QNetd

QNetd is an arbitrator that runs outside the cluster. The corosync-qnetd daemon provides a vote to the corosync-qdevice daemon on each node to help it participate in quorum decisions.

quorum

A cluster partition is defined to have quorum (be quorate) if it has the majority of nodes (or “votes”). Quorum distinguishes exactly one partition. This is part of the algorithm to prevent several disconnected partitions or nodes (“split brain”) from proceeding and causing data and service corruption. Quorum is a prerequisite for fencing, which then ensures that quorum is unique.

RA (resource agent)

A script acting as a proxy to manage a resource (for example, to start, stop or monitor a resource). SUSE Linux Enterprise High Availability supports different kinds of resource agents.

ReaR (Relax and Recover)

An administrator tool set for creating disaster recovery images.

resource

Any type of service or application that is known to Pacemaker, for example, an IP address, a file system, or a database. The term resource is also used for DRBD, where it names a set of block devices that use a common connection for replication.

resource constraint

Resource constraints specify which cluster nodes a resource can run on, what order the resources should start in, and which other resources a specific resource is dependent on.

See also colocation constraint, location constraint and order constraint.

resource set

As an alternative format for defining location, colocation or order constraints, you can use resource sets, where primitives are grouped together in one set. When creating a constraint, you can specify multiple resources for the constraint to apply to.

resource template

To help create many resources with similar configurations, you can define a resource template. After being defined, it can be referenced in primitives or in certain types of constraints. If a template is referenced in a primitive, the primitive inherits all operations, instance attributes (parameters), meta attributes and utilization attributes defined in the template.

SBD (STONITH Block Device)

SBD provides a node fencing mechanism through the exchange of messages via shared block storage. Alternatively, it can be used in diskless mode. In either case, it needs a hardware or software watchdog on each node to ensure that misbehaving nodes are really stopped.

scheduler

The scheduler is implemented as pacemaker-schedulerd. When a cluster transition is needed, pacemaker-schedulerd calculates the expected next state of the cluster and determines what actions need to be scheduled to achieve the next state.

split brain

A scenario in which the cluster nodes are divided into two or more groups that do not know about each other (either through a software or hardware failure). STONITH prevents a split-brain scenario from badly affecting the entire cluster. Also known as a partitioned cluster scenario.

The term split brain is also used in DRBD but means that the nodes contain different data.

SPOF (single point of failure)

Any component of a cluster that, if it fails, triggers the failure of the entire cluster.

stickiness

Resource stickiness is a meta attribute that determines how much a resource prefers to stay on its current node.

STONITH

Another term for the fencing mechanism that shuts down a misbehaving node to prevent it from causing trouble in a cluster. In a Pacemaker cluster, node fencing is managed by the fencing subsystem pacemaker-fenced.

switchover

The planned moving of resources to other nodes in a cluster. See also failover.

utilization

Tells the CRM what capacity a certain resource requires from a node.

watchdog

SBD (STONITH Block Device) needs a watchdog on each node to ensure that misbehaving nodes are really stopped. SBD “feeds” the watchdog by regularly writing a service pulse to it. If SBD stops feeding the watchdog, the hardware enforces a system restart. This protects against failures of the SBD process itself, such as becoming stuck on an I/O error.