[systemd-bugs] [Bug 54712] New: RFE: Simplify watchdog configuration on Servers with IPMI compatible hardware
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Sep 10 00:56:53 PDT 2012
https://bugs.freedesktop.org/show_bug.cgi?id=54712
Bug #: 54712
Summary: RFE: Simplify watchdog configuration on Servers with
IPMI compatible hardware
Classification: Unclassified
Product: systemd
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: general
AssignedTo: systemd-bugs at lists.freedesktop.org
ReportedBy: charles_rose at dell.com
QAContact: systemd-bugs at lists.freedesktop.org
Watchdog hardware on servers can typically be configured in three ways:
1. Configured via module parameters
The OpenIPMI project contains a startup script that loads IPMI kernel modules
during startup controlled by /etc/sysconfig/ipmi. This script can optionally
load ipmi_watchdog.ko as well.
/etc/sysconfig/ipmi
IPMI_WATCHDOG=yes
IPMI_WATCHDOG_OPTIONS="timeout=300 action=reset nowayout=0"
2. Configured pre-boot
IPMI Watchdog hardware support out-of-band configuration (pre-OS). This is
useful where the system admin wants to configure watchdog on systems from a
pre-os configuration utility (like use factory set defaults) or remotely with
tools like bmc-watchdog(8) for hundreds of systems.
3. Configured via a watchdog daemon
Systemd's RuntimeWatchdogSec, bmc-watchdog(8) or watchdog(5)
In scenarios #1 and #2, the timeout value is already set in the watchdog device
(the timer is set to Stopped). But systemd does not currently probe/use this.
For such scenarios, it would be beneficial if systemd can first get the current
timeout value (WDIOC_GETTIMEOUT), and if not set, only then set it to
RuntimeWatchdogSec. This would ensure that timeout values set via other
mechanisms still hold good and the system admin does not have to duplicate the
timeout values in /etc/systemd/system.conf (especially for large number of
systems, remotely).
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the systemd-bugs
mailing list