I have created software watchdog device using command: $ sudo modprobe softdog soft_margin=60 In OS log it is visible that software watchdog was initialized: Jul 12 09:49:00 patroni4 kernel: softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0) To trigger node reboot by the watchdog I have executed echo a | sudo tee /dev/watchdog. Node rebooted but in the logs there is no info that reboot was triggered by the watchdog. If I set option soft_noboot=1 in the OS log there is message softdog: Triggered - Reboot ignored. Based on the watchdog implementation there should be log message when node reboot was triggered by the watchdog. https://github.com/spacex/kernel-centos7/blob/master/drivers/watchdog/softdog.c

static void watchdog_fire(unsigned long data)
{
	if (soft_noboot)
		pr_crit("Triggered - Reboot ignored\n");
	else if (soft_panic) {
		pr_crit("Initiating panic\n");
		panic("Software Watchdog Timer expired");
	} else {
		pr_crit("Initiating system reboot\n");
		emergency_restart();
		pr_crit("Reboot didn't ?????\n");
	}
}

OS: CentOS Linux release 7.9.2009 (Core) Linux lin1 3.10.0-1160.62.1.el7.x86_64 How can I verify if reboot was triggered by the watchdog? Why this information is not logged? Can I enable logging somehow? Thank you for the info

Here's a line from a linux syslog: watchdog: shutting down the system because of error 101 However, after searching online and in man watchdog, I cannot find any discussion or explanation of the error codes. Is there any such thing?

I'm using the following system: - OS: Linux Mint 22.1 - Kernel: Linux 6.8.0-59-generic. - CPU: Ryzen 5 1600 - GPU: GT430C - Motherboard: B450M-A II - PSU: Corsair RM850 - BIOS 3002 - Microcode 0x08001138 From time to time, the PC beeps once and reboots. With BIOS 4609 and 4410, the PC could hang or reboot anywhere between 30 and 170 minutes. I'm using mdadm to create a RAID 6 and Samba to use the PC as NAS. The next time after it hung, I found this in the journal.

watchdog: BUG: soft lockup - CPU#2 stuck for 100s! [kcompactd0:100]
kernel: watchdog: BUG: soft lockup - CPU#4 stuck for 3855s! [gdbus:2699]

I would appreciate any info about this. Thanks. I read this [thread](https://forums.debian.net/viewtopic.php?t=148561) and seems like the first Ryzen generation/family has some issues, at least at that time. I wonder if this was solved in the current kernel?

I have been investigating to fix what appears to be a problem with systemd watchdog but with no success. I have a bunch of services that are of Type=notify. If the system time is set backwards, every service is killed by systemd because it thinks the watchdog timeout was hit. Here is the debug log from systemd systemd: xxx:service: Unit entered failed state. systemd: xxx:service: Failed with result 'watchdog'. Is there a way to tell Systemd not to restart services when the system time is changed manually? Shouldn't the watchdog depend on the CLOCK_MONOTONIC? Is this a known issue in Systemd?

How does one check the status of the hardware watchdog with systemd? With util-linux you have the wdctl command which prints some information, however this doesn't always work (e.g. on a Raspberry Pi 3 or later). For example on a Pi 3:

# wdctl /dev/watchdog0
wdctl: cannot read information about /dev/watchdog0: No such file or directory
# wdctl /dev/watchdog
wdctl: cannot read information about /dev/watchdog: No such file or directory

However the watchdog appears to be active:

# dmesg | grep watchdog
[    6.985782] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[   17.190956] systemd: Using hardware watchdog 'Broadcom BCM2835 Watchdog timer', version 0, device /dev/watchdog
[   17.206391] systemd: Set hardware watchdog to 15s.

So is there a systemd-specific command that can be used to display the current status of the hardware watchdog and what systemd itself is doing with it? Note that the old watchdog service no longer applies, as this was from before systemd got native hardware watchdog support:

# systemctl status watchdog
Unit watchdog.service could not be found.

I am after a command that provides similar information to wdctl, in that the watchdog timer is active, in use, and what the timeout is currently set to. Sort of like systemctl list-timers but for the hardware watchdog.

My server is experiencing random reboots, and I haven't been able to locate any logs explaining the cause. Below are the system details. OS: Debian 12.8 (bookworm) Hardware: SMC (SYS-111E-FWTR) kernel: Linux Dev-test 6.1.0-28-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux Drivers: ice (v1.15.5) iavf(v4.12.6) mlx5_core(24.10-1.1.4) ipmitool mc watchdog get Watchdog Timer Use: SMS/OS (0x44) Watchdog Timer Is: Started/Running Watchdog Timer Logging: On Watchdog Timer Action: No action (0x00) Pre-timeout interrupt: None Pre-timeout interval: 0 seconds Timer Expiration Flags: (0x10) * SMS/OS Initial Countdown: 300.0 sec Present Countdown: 249.5 sec last reboot reboot system boot 6.1.0-28-rt-amd6 Wed Feb 26 08:46 still running reboot system boot 6.1.0-28-rt-amd6 Wed Feb 26 07:18 - 08:43 (01:25) reboot system boot 6.1.0-28-rt-amd6 Tue Feb 25 20:42 - 08:43 (12:01) ~# uptime 10:15:03 up 1:28, 7 users, load average: 7.28, 7.76, 7.75 :~# date Wed Feb 26 10:15:05 AM EAT 2025 ~# HISTTIMEFORMAT='%Y-%m-%d %H:%M:%S ' history | grep reboot 186 2025-02-26 08:47:45 reboot 203 2025-02-26 08:47:45 reboot 250 2025-02-26 08:47:45 reboot 267 2025-02-26 08:47:45 reboot' I tried disabling watchdog action by suspecting wdt causing reboot. Verified dmesg and journal logs but no clue.

I'm getting a crash on my system. systemd-udev.service is crashing as seen in the logs below:

Apr 03 20:15:04 dut-3 charon-systemd: sending keep alive to 194.1.1.1
Apr 03 20:15:04 dut-3 charon-systemd: sending keep alive to 194.1.1.1
Apr 03 20:15:04 dut-3 charon-systemd: sending keep alive to 194.1.1.1
Apr 03 20:19:07 dut-3 systemd: Created slice system-systemd\x2dcoredump.slice - Slice /system/systemd-coredump.
Apr 03 20:19:07 dut-3 systemd: Started systemd-coredump@0-276426-0.service - Process Core Dump (PID 276426/UID 0).
Apr 03 20:19:07 dut-3 systemd: systemd-udevd.service: State 'stop-watchdog' timed out. Killing.
Apr 03 20:19:07 dut-3 systemd: systemd-udevd.service: Killing process 1546 (systemd-udevd) with signal SIGKILL.
Apr 03 20:19:07 dut-3 systemd: Started systemd-coredump@1-276430-0.service - Process Core Dump (PID 276430/UID 0).
...
Apr 03 20:19:07 dut-3 systemd: systemd-journald.service: Failed with result 'watchdog'.
...
Apr 03 20:17:00 dut-3 systemd: systemd-udevd.service: Watchdog timeout (limit 3min)!

In trying to debug the crash, I'm wondering if the crash is due to the watchdog timeout or if the watchdog timeout occurs because of the crash. Specifically, systemd-udevd.service has crash and isn't able to send a message to the watchdog.

I am running Linux on a hardware that has a 16 second hardware watchdog timer (sunxi-wdt 1c20c90.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)). I set in watchdog.conf: watchdog-device = /dev/watchdog watchdog-timeout = 16 interval = 10 I want to ping a host with relaxed timing (every ~5 minutes) but watchdog.conf says that the ping test is executed every interval. My network link can take more than 10 seconds to come up after startup so I guess I could end up in a reboot loop. Is there a way to relax ping timing in the watchdog daemon itself or do I need to write a custom test script?

I want to read the Intel iTCO watchdog registers on my Intel Lynx Point system. I found the watchdog here: [ 5598.341020] iTCO_wdt iTCO_wdt.1.auto: Found a Lynx Point TCO device (Version=2, TCOBASE=0x1860) It is connected to the ISA bridge LPC controller: 00:1f.0 ISA bridge: Intel Corporation H87 Express LPC Controller (rev 05) Subsystem: ASUSTeK Computer Inc. H87 Express LPC Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: lpc_ich Kernel modules: lpc_ich I found the ioports: cat /proc/ioports | grep -i tco 1830-1833 : iTCO_wdt.1.auto 1830-1833 : iTCO_wdt 1860-187f : iTCO_wdt.1.auto 1860-187f : iTCO_wdt And I found the iomem: cat /proc/iomem | grep -i wdt fed1f410-fed1f414 : iTCO_wdt.0.auto I tried to dump the memory via: memtool md 0xfed1f410 Then I set the timeout to a different value and compare the registers again: wdctl -s 10 memtool md 0xfed1f410 Nothing changes, why is that? What is wrong with my approach?

At shutdown I often get the message watchdog did not stop! and then the laptop freezes after few other lines without shutting down. Any idea on how to fix this? Recently it happened very often, usually when the laptop was powered on for some time. I am using Debian 8 on an Asus UX32LA I found this systemd file (it shows a conflict with the shutdown.target), if it may help. My impression is that the problem depends on some issue coming from me trying to fix the backlight (which actually only works with the grub paramenter "acpi_osi=" ) [Unit] Description=Load/Save Screen Backlight Brightness of %i Documentation=man:systemd-backlight@.service(8) DefaultDependencies=no RequiresMountsFor=/var/lib/systemd/backlight Conflicts=shutdown.target After=systemd-readahead-collect.service systemd-readahead-replay.service systemd-remount-fs.service Before=sysinit.target shutdown.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/systemd/systemd-backlight load %i ExecStop=/lib/systemd/systemd-backlight save %i

I have a hardware watchdog, what is a good way to test that it actually works? Is there a standard script or such to set my system in an infinite loop to hog all resources or such to the point of triggering the hardware watchdog?

My systemctl Code dont work

@raspberrypi:~ $ sudo systemctl status 
● .service
   Loaded: loaded (/etc/systemd/system/.service; disabled; vendor prese
   Active: failed (Result: exit-code) since Mon 2022-04-04 21:55:20 CEST; 4s ago
  Process: 1686 ExecStart=/usr/bin/npm start (code=exited, status=203/EXEC)
 Main PID: 1686 (code=exited, status=203/EXEC)

Apr 04 21:55:20 raspberrypi systemd: .service: Service RestartSec=50
Apr 04 21:55:20 raspberrypi systemd: .service: Scheduled restart job
Apr 04 21:55:20 raspberrypi systemd: Stopped .service.
Apr 04 21:55:20 raspberrypi systemd: .service: Start request repeate
Apr 04 21:55:20 raspberrypi systemd: .service: Failed with result 'e
Apr 04 21:55:20 raspberrypi systemd: Failed to start .service.

systemctl reset-failed 
systemctl start

^^Dont work Can anyone help?

Any way to register application with systemd watchdog at runtime ? I mean don't use systemd unit file, via systemd API for example Linux watchdog is used for system reset only ? Can it be used for application reset ?

I'm kinda new to bash scripting so bear with me. I have a program that prints logs almost every second into a file. I want it to restart if current time is few mins more than the file's last modification time.

Apologies if I am missing details, I may not be aware of all the areas on systemd I am trying to make my phosphor-watchdog service start automatically after another service, I cannot understand why it is by default disabled. > /lib/systemd/system# ls |grep phosphor-watchdog > > phosphor-watchdog@.service > > phosphor-watchdog@poweron.service.d /lib/systemd/system# systemctl status phosphor-watchdog@poweron.service ● phosphor-watchdog@poweron.service - Phosphor poweron watchdog Loaded: loaded (/lib/systemd/system/phosphor-watchdog@.service; disabled; vendor preset: enabled) Drop-In: /lib/systemd/system/phosphor-watchdog@poweron.service.d └─poweron.conf Active: inactive (dead) this is the service file for phosphor-watchdog service : [Unit] Description=Phosphor %I watchdog Conflicts=host-force-poweroff@0.service After=pwr-monitor.service [Service] Restart=always EnvironmentFile={envfiledir}/obmc/watchdog/%I ExecStart=/usr/bin/env phosphor-watchdog --continue --service=${{SERVICE}} --path=${{DEVPATH}} --target=${{TARGET}} SyslogIdentifier=phosphor-watchdog [Install] WantedBy=multi-user.target and for phosphor-watchdog@poweron.service.d/poweron.conf: [Unit] Conflicts=obmc-host-stop@0.target Conflicts=obmc-chassis-poweroff@0.target Conflicts=obmc-host-quiesce@0.target I am wondering why is my service always disabled despite the presence of "WantedBy=multi-user.target" FYI: with systemctl enable everything works fine, but I want it to be enabled by default. please let me know if I need to give further information. Thank you.

I configured my watchdog.conf, and i want try if my computer restart when it crash. so, I wanted kill my Watchdog to try if my computer will restart. But I try to killed it with the command "kill -9 90" and "killall -s SIGKILL watchdog" but neither of two successfulled. If someone have an idea to kill the watchdogd ? Best regards.

Is there a command like vi > out vi | out That I could use to cause a watchdog reset of my embedded linux device?

On an Orange Pi Zero running a Raspbian server, it's possible to use the watchdog very easily just by running the command echo 1 > /dev/watchdog as root. The idea is that the system will certainly reboot after some time that this command is executed, so I need to keep repeating this command in a regular interval of time to keep the system on. We can implement a watchdog using cron as root and making it execute the following script on boot: #!/bin/bash while [ true ]; do echo 1 > /dev/watchdog sleep 5 done This script works fine on the Orange Pi Zero... However, on my desktop computer running Ubuntu 18.04 the command echo 1 > /dev/watchdog doesn't work at all. **Is it possible to activate the watchdog on any device running Linux?**

Broadcast message from username@Desktop (Sun 1919-08-10 11:45:14 CST):

The system is going to reboot NOW!

[756.345947] watchdog: watchdog0: watchdog did not stop!
[756.472889] watchdog: watchdog0: watchdog did not stop!

Every time I reboot and found a message like this. Is there any way to get rid of these messages? I used to have a /etc/modprobe.d/watchdog.conf and blacklisted:

blacklist iTCO_wdtblacklist 
blacklist iTCO_vendor_support

but now it does not work

[firestar@ThinkPad ~]$ inxi -b
System:
  Host: ThinkPad Kernel: 5.18.10-1-MANJARO arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.24.5 Distro: Manjaro Linux
Machine:
  Type: Laptop System: LENOVO product: 20WKA000CD v: ThinkPad X13 Gen 2i
    serial: 
  Mobo: LENOVO model: 20WKA000CD v: SDK0L77769 WIN
    serial:  UEFI: LENOVO v: N35ET47W (1.47 )
    date: 05/13/2022
Battery:
  ID-1: BAT0 charge: 54.7 Wh (100.0%) condition: 54.7/54.7 Wh (100.0%)
CPU:
  Info: quad core 11th Gen Intel Core i7-1165G7 [MT MCP] speed (MHz):
    avg: 897 min/max: 400/4700
Graphics:
  Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
  Device-2: IMC Networks Integrated RGB Camera type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 21.1.3 driver: X: loaded: modesetting
    gpu: i915 resolution: 2560x1600~60Hz
  OpenGL: renderer: Mesa Intel Xe Graphics (TGL GT2) v: 4.6 Mesa 22.1.3
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Intel Wi-Fi 6 AX210/AX211/AX411 160MHz driver: iwlwifi
Drives:
  Local Storage: total: 953.87 GiB used: 29.01 GiB (3.0%)
Info:
  Processes: 221 Uptime: 10m Memory: 15.35 GiB used: 2.68 GiB (17.5%)
  Shell: Bash inxi: 3.3.19

In view of **enabling the watchdog** on my **Raspberry Pi 4** running Raspbian (raspberry pi OS) I have modified /etc/systemd/system.conf by uncommenting the following three lines: RuntimeWatchdogSec=2min RebootWatchdogSec=10min DefaultTimeoutStopSec=10s Now my raspberry is locked in an **infinite boot loop** rebooting every ~2 minutes which is weirdly very similar to the RuntimeWatchdogSec value. I have tried to modify the /etc/systemd/system.conf on the SD card using another computer but this does not seem to be the way to go as this file is always being overwritten. What would be the way to restore these settings by either a) only accessing the SD card from another computer or b) somehow entering a rescue mode/terminal during startup before systemd enables this nasty watchdog.