`crm sbd status` to print and WARN the sbd configuration mtime while sbd.service is active

[zzhou1]

As the title. Ideally, the suggestion could be something like the following mock-up

adm@tw-1:~> sudo crm sbd status
# Type of SBD:
Disk-based SBD: its sysconfig file is modified at  Wed 2025-06-25 07:14:48 CEST

# Status of sbd.service:
Node   |Active  |Enabled |Since
tw-1  |YES     |YES     |active since: Wed 2025-06-25 07:13:48 CEST
tw-2  |YES     |YES     |active since: Wed 2025-06-25 04:03:32 CEST
tw-3  |NO      |YES     |disactive since: Wed 2025-06-25 08:16:59 CEST

WARN:  /etc/sysconfig/sbd was modified while sbd.service is active. Restarting sbd is highly suggested.


REF:

adm@tw-1:~> stat -c %y /etc/sysconfig/sbd | xargs -I {} date -d {} "+%a %Y-%m-%d %H:%M:%S %Z"
Tue 2025-06-24 04:25:31 CEST

[liangxin1300]

Implement in #1848

[liangxin1300]

# crm sbd status
# Type of SBD:
Disk-based SBD configured, /etc/sysconfig/sbd modified at Fri 2025-06-27 16:00:47 CST

# Status of sbd.service:
Node   |Active  |Enabled |Since
alp-1  |YES     |YES     |active since: Fri 2025-06-27 15:52:14 CST
alp-2  |YES     |YES     |active since: Fri 2025-06-27 15:52:14 CST

WARNING: /etc/sysconfig/sbd was modified while sbd is active. Restart cluster service is highly recommended.

# Status of the sbd disk watcher process on alp-1:
├─10257 sbd: watcher: /dev/sda6 - slot: 1 - uuid: b33cb14d-ec1c-4195-abca-de8ccc603622

# Status of the sbd disk watcher process on alp-2:
├─11122 sbd: watcher: /dev/sda6 - slot: 0 - uuid: b33cb14d-ec1c-4195-abca-de8ccc603622

# Watchdog info:
Node   |Device          |Driver    |Kernel Timeout
alp-1  |/dev/watchdog0  |iTCO_wdt  |10
alp-2  |/dev/watchdog0  |iTCO_wdt  |10

# Status of fence_sbd:
resource stonith-sbd is running on: alp-1

[liangxin1300]

Here is one issue: after run crm cluster init sbd -s <dev> -y on a running cluster:

...
INFO: Initializing SBD device /dev/sda6
INFO: Update SBD_DEVICE in /etc/sysconfig/sbd: /dev/sda6
INFO: Update SBD_WATCHDOG_DEV in /etc/sysconfig/sbd: /dev/watchdog0
INFO: Already synced /etc/sysconfig/sbd to all nodes
INFO: Enable sbd.service on node alp-1
INFO: Enable sbd.service on node alp-2
INFO: Restarting cluster service
INFO: BEGIN Waiting for cluster
..........                                                                                                                                                                                         
INFO: END Waiting for cluster
WARNING: "stonith-enabled" in crm_config is set to true, it was false
INFO: Add parameter 'pcmk_delay_max=30s' for resource 'stonith-sbd'
INFO: Update SBD_DELAY_START in /etc/sysconfig/sbd: 41
INFO: Already synced /etc/sysconfig/sbd to all nodes

run crm sbd status will get:

# crm sbd status
# Type of SBD:
Disk-based SBD configured, /etc/sysconfig/sbd modified at Fri 2025-06-27 16:41:36 CST

# Status of sbd.service:
Node   |Active  |Enabled |Since
alp-1  |YES     |YES     |active since: Fri 2025-06-27 16:41:11 CST
alp-2  |YES     |YES     |active since: Fri 2025-06-27 16:41:15 CST

WARNING: /etc/sysconfig/sbd was modified while sbd is active. Restart cluster service is highly recommended.

# Status of the sbd disk watcher process on alp-1:
├─15591 sbd: watcher: /dev/sda6 - slot: 0 - uuid: f5ddadd9-5614-458b-92d7-e69c10c0405c

# Status of the sbd disk watcher process on alp-2:
├─16261 sbd: watcher: /dev/sda6 - slot: 1 - uuid: f5ddadd9-5614-458b-92d7-e69c10c0405c

# Watchdog info:
Node   |Device          |Driver    |Kernel Timeout
alp-1  |/dev/watchdog0  |iTCO_wdt  |10
alp-2  |/dev/watchdog0  |iTCO_wdt  |10

# Status of fence_sbd:
resource stonith-sbd is running on: alp-1

sbd.service will be started before sysconfig/sbd changed

[liangxin1300]

Alternatively, I believe this issue is invalid.
As you know, the metadata on the SBD device has higher priority than the settings in sysconfig/sbd. The value stored in sysconfig/sbd is mainly used when the node is rebooted.

[zzhou1]

Not really. There are other parameters outside of disk-metadata, diskless-sbd is not part of your argument.

This warning is a useful hint a the general level, the straight forward example is when /etc/sysconfig/sbd is modified outside of crmsh, example by ansible playbook

The example in #1837 (comment)
is because SBD_DELAY_START change is not the runtime parameter of sbd process. Ideally, we could move this step earlier before restarting the cluster stack to avoid the chaos of this WARN.

[liangxin1300]

Ideally, we could move this step earlier before restarting the cluster stack to avoid the chaos of this WARN.

Please create a sub-issue for this

[liangxin1300]

is because SBD_DELAY_START change is not the runtime parameter of sbd process

The formula to calculate SBD_DELAY_START:
https://github.com/ClusterLabs/crmsh/blob/master/crmsh/sbd.py#L341
It relies on the token and consensus, requires running corosync

[liangxin1300]

is because SBD_DELAY_START change is not the runtime parameter of sbd process

The formula to calculate SBD_DELAY_START: https://github.com/ClusterLabs/crmsh/blob/master/crmsh/sbd.py#L341 It relies on the token and consensus, requires running corosync

So I still think this issue is invalid