Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 1812206 [details] The kernel logs 1. Please describe the problem: When I reboot, the following message appears: watchdog: watchdog0: watchdog did not stop! 2. What is the Version-Release number of the kernel: 5.14.0-0 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : I don't know. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 1. Start rebooting. 2. Before the system finishes shutting down, watch the console output carefully. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes. 6. Are you running any modules that not shipped with directly Fedora's kernel?: I’m pretty sure that the answer is no, but I don’t know how to check. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag.
This report has not received an update in over 90 days. If this issue is still relevant to you, please do not hesitate to update this report with any relevant details on recent investigative steps or changes and we will absolutely work to understand how to best move forward. Otherwise, this bug report will need to be closed in 30 days. No worries, however; should you need still assistance after the report is closed, please do not hesitate to create a new bug report referencing this report and with any new details on the matter. NOTE: This is an automated mass update.
I am still able reproduce this bug with the latest version of Fedora Rawhide. Specifically, I’m able to reproduce this bug with this kernel package: kernel-7.2.0-0.rc5.41.fc45.x86_64.
It isn't exactly obvious why it may be omitting that message, so I took a look at what could cause the log line to be omitted. In taking a look at that error message, it appears to be printed in the following location in the kernel; $ git grep -n 'watchdog did not stop' drivers/watchdog/watchdog_dev.c:963: pr_crit("watchdog%d: watchdog did not stop!\n", wdd->id); And the overall context where this is executed is as follows; drivers/watchdog/watchdog_dev.c: 937 static int watchdog_release(struct inode *inode, struct file *file) 938 { 939 struct watchdog_core_data *wd_data = file->private_data; 940 struct watchdog_device *wdd; 941 int err = -EBUSY; 942 bool running; 943 944 mutex_lock(&wd_data->lock); 945 946 wdd = wd_data->wdd; 947 if (!wdd) 948 goto done; 949 950 /* 951 * We only stop the watchdog if we received the magic character 952 * or if WDIOF_MAGICCLOSE is not set. If nowayout was set then 953 * watchdog_stop will fail. 954 */ 955 if (!watchdog_active(wdd)) 956 err = 0; 957 else if (test_and_clear_bit(_WDOG_ALLOW_RELEASE, &wd_data->status) || 958 !(wdd->info->options & WDIOF_MAGICCLOSE)) 959 err = watchdog_stop(wdd); drivers/watchdog/watchdog_dev.c: 282 /** 283 * watchdog_stop - wrapper to stop the watchdog 284 * @wdd: The watchdog device to stop 285 * 286 * Stop the watchdog if it is still active and unmark it active. 287 * If the 'nowayout' feature was set, the watchdog cannot be stopped. 288 * The caller must hold wd_data->lock. 289 * 290 * Return: 0 on success or a negative errno code for failure. 291 */ 292 static int watchdog_stop(struct watchdog_device *wdd) 293 { 294 int err = 0; 295 296 if (!watchdog_active(wdd)) 297 return 0; 298 299 if (test_bit(WDOG_NO_WAY_OUT, &wdd->status)) { 300 pr_info("watchdog%d: nowayout prevents watchdog being stopped!\n", 301 wdd->id); 302 return -EBUSY; 303 } 304 305 if (wdd->ops->stop) { 306 clear_bit(WDOG_HW_RUNNING, &wdd->status); 307 err = wdd->ops->stop(wdd); 308 trace_watchdog_stop(wdd, err); 309 } else { 310 set_bit(WDOG_HW_RUNNING, &wdd->status); 311 } 312 313 if (err == 0) { 314 clear_bit(WDOG_ACTIVE, &wdd->status); 315 watchdog_update_worker(wdd); 316 watchdog_hrtimer_pretimeout_stop(wdd); 317 } 318 319 return err; 320 } 960 961 /* If the watchdog was not stopped, send a keepalive ping */ 962 if (err < 0) { 963 pr_crit("watchdog%d: watchdog did not stop!\n", wdd->id); Essentially, in the above, when the kernel goes to close out a watchdog, it checks to see if it has its respective `nowayout` parameter set and bails omitted an informational message in doing so. `nowayout` is not typically set by default and is generally only set in very specific environments; fortunately the logs you provided confirm `nowayout` is not set; ... Aug 08 17:30:42 kernel: iTCO_vendor_support: vendor-support=0 Aug 08 17:30:42 kernel: iTCO_wdt iTCO_wdt.1.auto: Found a ICH9 TCO device (Version=2, TCOBASE=0x0660) Aug 08 17:30:42 kernel: iTCO_wdt iTCO_wdt.1.auto: initialized. heartbeat=30 sec (nowayout=0) <--- ... The logs also tell me it is a iTCO watchdog which helps narrow down where to look. The following location is likely where the kernel attempts to stop the watchdog; ... 305 if (wdd->ops->stop) { 306 clear_bit(WDOG_HW_RUNNING, &wdd->status); 307 err = wdd->ops->stop(wdd); 308 trace_watchdog_stop(wdd, err); ... The `wdd->ops` typically means a generic set of "operations" are assigned within the specific device implementation, and there's a _lot_ of different hardware watchdogs. The logs indicate we have a iTCO watchdog, so let's check there for the stop function assignment. include/linux/watchdog.h: 102 struct watchdog_device { ... 107 const struct watchdog_ops *ops; ... include/linux/watchdog.h: 48 struct watchdog_ops { ... 52 /* optional operations */ 53 int (*stop)(struct watchdog_device *); ... And the iTCO-specific implementation; $ git grep watchdog_ops | grep -i itco drivers/watchdog/iTCO_wdt.c:static const struct watchdog_ops iTCO_wdt_ops = { 440 static const struct watchdog_ops iTCO_wdt_ops = { ... 443 .stop = iTCO_wdt_stop, ... And it is defined below; 308 static int iTCO_wdt_stop(struct watchdog_device *wd_dev) 309 { 310 struct iTCO_wdt_private *p = watchdog_get_drvdata(wd_dev); 311 unsigned int val; 312 313 /* Bit 11: TCO Timer Halt -> 1 = The TCO timer is disabled */ 314 val = inw(TCO1_CNT(p)); 315 val |= 0x0800; 316 outw(val, TCO1_CNT(p)); 317 val = inw(TCO1_CNT(p)); 318 319 /* Set the NO_REBOOT bit to prevent later reboots, just for sure */ 320 p->update_no_reboot_bit(p->no_reboot_priv, true); 321 322 if ((val & 0x0800) == 0) 323 return -1; 324 return 0; 325 } So the function quite genuinely _just_ sets a specific bit and writes that to the iTCO device, then reads it back to see if it was set. If not, return -1. This last part means that we likely can't use the trace_watchdog_stop() call in watchdog_stop; ... 305 if (wdd->ops->stop) { 306 clear_bit(WDOG_HW_RUNNING, &wdd->status); 307 err = wdd->ops->stop(wdd); 308 trace_watchdog_stop(wdd, err); ... As it seems to only report the watchdog device and error message; include/trace/events/watchdog.h: 11 DECLARE_EVENT_CLASS(watchdog_template, 12 13 TP_PROTO(struct watchdog_device *wdd, int err), 14 15 TP_ARGS(wdd, err), 16 17 TP_STRUCT__entry( 18 __field(int, id) 19 __field(int, err) 20 ), 21 22 TP_fast_assign( 23 __entry->id = wdd->id; 24 __entry->err = err; 25 ), 26 27 TP_printk("watchdog%d err=%d", __entry->id, __entry->err) <-- what gets printed 28 ); ... 38 DEFINE_EVENT(watchdog_template, watchdog_stop, 39 TP_PROTO(struct watchdog_device *wdd, int err), 40 TP_ARGS(wdd, err)); ... All of that is to say we pass a specific value to the iTCO device to tell it to stop, that value doesn't get set, and then we warn that we couldn't stop the watchdog. Your logs indicate the system is a VM on qemu hosted on archlinux; ... Aug 08 17:30:40 kernel: SMBIOS 2.8 present. Aug 08 17:30:40 kernel: DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS ArchLinux 1.14.0-1 04/01/2014 Aug 08 17:30:40 kernel: Hypervisor detected: KVM ... When testing on my VM hosted similarly but with Fedora as the host, I was able to reproduce it; # for i in {1..5}; do journalctl --no-hostname -k -b $i | grep -e watchdog -e 'Linux version'; echo; done Jul 27 18:14:10 kernel: Linux version 6.19.10-300.fc44.x86_64 (mockbuild@4ae50e2f6b614b1a809cc64e77352d92) (gcc (GCC) 16.0.1 20260321 (Red Hat 16.0.1-0), GNU ld version 2.46-1.fc44) #1 SMP PREEMPT_DYNAMIC Wed Mar 25 18:23:49 UTC 2026 Jul 31 14:53:27 kernel: Linux version 7.1.5-200.fc44.x86_64 (mockbuild@554b29c8a91e4478ad9a7e8fbed56962) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #1 SMP PREEMPT_DYNAMIC Fri Jul 24 20:44:56 UTC 2026 Jul 31 15:01:18 kernel: watchdog: watchdog0: watchdog did not stop! Jul 31 15:01:18 systemd-shutdown[1]: Using hardware watchdog /dev/watchdog0: 'iTCO_wdt', version 2. Jul 31 15:01:26 kernel: Linux version 7.1.5-200.fc44.x86_64 (mockbuild@554b29c8a91e4478ad9a7e8fbed56962) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #1 SMP PREEMPT_DYNAMIC Fri Jul 24 20:44:56 UTC 2026 Jul 31 15:21:03 kernel: watchdog: watchdog0: watchdog did not stop! Jul 31 15:21:03 systemd-shutdown[1]: Using hardware watchdog /dev/watchdog0: 'iTCO_wdt', version 2. Jul 31 15:21:22 kernel: Linux version 7.2.0-0.rc5.260729gfc02acf6ac0c.43.fc45.x86_64 (mockbuild@789302b3af944880bd0dc1d7f8099ab9) (gcc (GCC) 16.1.1 20260703 (Red Hat 16.1.1-4), GNU ld version 2.47.20260726) #1 SMP PREEMPT_DYNAMIC Wed Jul 29 21:54:22 UTC 2026 Jul 31 16:04:46 kernel: watchdog: watchdog0: watchdog did not stop! Jul 31 16:04:46 systemd-shutdown[1]: Using hardware watchdog /dev/watchdog0: 'iTCO_wdt', version 2. Jul 31 16:04:55 kernel: Linux version 7.2.0-0.rc5.260729gfc02acf6ac0c.43.fc45.x86_64 (mockbuild@789302b3af944880bd0dc1d7f8099ab9) (gcc (GCC) 16.1.1 20260703 (Red Hat 16.1.1-4), GNU ld version 2.47.20260726) #1 SMP PREEMPT_DYNAMIC Wed Jul 29 21:54:22 UTC 2026 Jul 31 16:15:26 kernel: watchdog: watchdog0: watchdog did not stop! Jul 31 16:15:26 systemd-shutdown[1]: Using hardware watchdog /dev/watchdog0: 'iTCO_wdt', version 2. It didn't happen on the 6.19 kernel but I was also running a different version of qemu so it could have been a change in qemu and not the kernel. Actually on that point, I think this is a QEMU/KVM issue on the host and not necessarily a iTCO issue in the guest, mostly because, when checking the changes over iTCO between the last kernel version that didn't show the warning on my VM and the first kernel version that I see this error of the installed kernels, not much has changed; $ git log --no-merges --oneline kernel-6.19.10-0..kernel-7.1.5-0 drivers/watchdog/iTCO_wdt.c 0bf75b9c8a watchdog: iTCO: Drop vendor support And this commit quite genuinely just drops support for old hardware; commit 0bf75b9c8a0eb1ef46ce85a393dd27ae801fc207 Author: Guenter Roeck <linux> Date: Tue Nov 18 11:29:58 2025 -0800 watchdog: iTCO: Drop vendor support iTCO vendor support was introduced in 2006 to support SuperMicro boards with Pentium 3 CPUs. It was extended in 2009 to support motherbords with broken BIOS (specifically Intel DG33TL). The code is long since obsolete, so let's drop support for it. I can attempt to start looking into the watchdog bits in qemu/kvm. That being said, the warning is not inherently problematic. If the concern is seeing a warning in the logs, the watchdog can be disabled. This watchdog is only used to be able to hard reset a system from hardware if you arm it. Disabling should be as simple as blocklisting the iTCO_wdt module. However, is the concern something else?
> I can attempt to start looking into the watchdog bits in qemu/kvm. That being said, the warning is not inherently problematic. If the concern is seeing a warning in the logs, the watchdog can be disabled. This watchdog is only used to be able to hard reset a system from hardware if you arm it. Disabling should be as simple as blocklisting the iTCO_wdt module. However, is the concern something else? I mean, I reported this bug because the message “watchdog: watchdog0: watchdog did not stop!” indicates that something is wrong. From my perspective as a user, if I see a message like that, then it indicates to me that either I’ve done something wrong or that there’s a bug. This particular message appears even if I do a fresh install of Fedora which indicates that this is a bug. I’m not really concerned about any particular bad thing happening as a result of this bug. Instead, I reported this bug because it would be better if this bug got fixed than if this bug never got fixed.
Understood and thank you for the clarification. My apologies if it seemed like I wouldn't be helping progress this; my intent was more to ensure there wasn't a larger concern that the message was something to be far more concerned about. I wanted to see if there was a way to trace the value as it is coming and going in iTCO_wdt_stop, however, there's not a lot of surface area to trace; === root@fedora:~# perf probe -m iTCO_wdt -L drivers/watchdog/iTCO_wdt.c ... 308 static int iTCO_wdt_stop(struct watchdog_device *wd_dev) { 310 struct iTCO_wdt_private *p = watchdog_get_drvdata(wd_dev); 311 unsigned int val; /* Bit 11: TCO Timer Halt -> 1 = The TCO timer is disabled */ val = inw(TCO1_CNT(p)); val |= 0x0800; outw(val, TCO1_CNT(p)); 317 val = inw(TCO1_CNT(p)); /* Set the NO_REBOOT bit to prevent later reboots, just for sure */ p->update_no_reboot_bit(p->no_reboot_priv, true); 322 if ((val & 0x0800) == 0) return -1; return 0; } ... === However, it looks like QEMU's iTCO implementation has some options for tracing around that value being written to or read from; https://github.com/qemu/qemu/blob/master/hw/acpi/ich9_tco.c#L136 I am not intimately familiar with qemu at this level, however, so I will need to get this to the right group.
(In reply to Charles Haithcock from comment #3) > And the overall context where this is executed is as follows; > > > > drivers/watchdog/watchdog_dev.c: > 937 static int watchdog_release(struct inode *inode, struct file *file) > 938 { > 939 struct watchdog_core_data *wd_data = file->private_data; > 940 struct watchdog_device *wdd; > 941 int err = -EBUSY; Note here, 'err' is set to EBUSY and.... > 942 bool running; > 943 > 944 mutex_lock(&wd_data->lock); > 945 > 946 wdd = wd_data->wdd; > 947 if (!wdd) > 948 goto done; > 949 > 950 /* > 951 * We only stop the watchdog if we received the magic character > 952 * or if WDIOF_MAGICCLOSE is not set. If nowayout was set then > 953 * watchdog_stop will fail. > 954 */ > 955 if (!watchdog_active(wdd)) > 956 err = 0; > 957 else if (test_and_clear_bit(_WDOG_ALLOW_RELEASE, > &wd_data->status) || > 958 !(wdd->info->options & WDIOF_MAGICCLOSE)) > 959 err = watchdog_stop(wdd); ....here there is no final 'else' clause, so...... > 960 > 961 /* If the watchdog was not stopped, send a keepalive ping */ > 962 if (err < 0) { > 963 pr_crit("watchdog%d: watchdog did not stop!\n", > wdd->id); ....This cannot be assumed to reflect an error. It can be printed if Either * Userspace opened /dev/watchdog0 and then closed it without writing the magic "V" character to disable the watchdog timer, taking the code path through the non-existant "else" thus leaving 'err == EBUSY' Or * Userspace wrote "V" character and 'watchdog_stop()' returned an error. > Hat 16.0.1-0), GNU ld version 2.46-1.fc44) #1 SMP PREEMPT_DYNAMIC Wed Mar 25 > 18:23:49 UTC 2026 > > Jul 31 14:53:27 kernel: Linux version 7.1.5-200.fc44.x86_64 > (mockbuild@554b29c8a91e4478ad9a7e8fbed56962) (gcc (GCC) 16.1.1 20260515 (Red > Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #1 SMP PREEMPT_DYNAMIC Fri Jul > 24 20:44:56 UTC 2026 > Jul 31 15:01:18 kernel: watchdog: watchdog0: watchdog did not stop! > Jul 31 15:01:18 systemd-shutdown[1]: Using hardware watchdog /dev/watchdog0: > 'iTCO_wdt', version 2. This is systemd-shutdown opening the HW watchdog device: https://github.com/systemd/systemd/blob/main/src/shutdown/shutdown.c#L274 when systemd is done shuting off, it explicitly does NOT disable the watchdog: https://github.com/systemd/systemd/blob/main/src/shutdown/shutdown.c#L592 So we know from that watchdog_release() is going to take the non-existant 'else' path and see EBUSY. TLDR: seeing "watchdog0: watchdog did not stop!" is normal expected behaviour given that systemd closes the device without disabling the watchdog
Re-assigning back to the kernel, as IMHO, the kernel ought to print different messages for the error in 'dev_stop' scenario, vs the non-error "userspace didn't disable the watchdog" scenario Something along the lines of this: diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c index d7895009a2de..d67c4b2ec7eb 100644 --- a/drivers/watchdog/watchdog_dev.c +++ b/drivers/watchdog/watchdog_dev.c @@ -955,12 +955,17 @@ static int watchdog_release(struct inode *inode, struct file *file) if (!watchdog_active(wdd)) err = 0; else if (test_and_clear_bit(_WDOG_ALLOW_RELEASE, &wd_data->status) || - !(wdd->info->options & WDIOF_MAGICCLOSE)) + !(wdd->info->options & WDIOF_MAGICCLOSE)) { err = watchdog_stop(wdd); + if (err < 0) { + pr_crit("watchdog%d: watchdog did not stop!\n", wdd->id); + } + } else { + pr_info("watchdog%d: watchdog was left running!\n", wdd->id); + } /* If the watchdog was not stopped, send a keepalive ping */ if (err < 0) { - pr_crit("watchdog%d: watchdog did not stop!\n", wdd->id); watchdog_ping(wdd); }
Ah good catch! Thank you, I didn't anticipate it being expected behavior for systemd. I tested out the following; > diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c > index d7895009a2..a571dea353 100644 > --- a/drivers/watchdog/watchdog_dev.c > +++ b/drivers/watchdog/watchdog_dev.c > @@ -955,14 +955,17 @@ static int watchdog_release(struct inode *inode, struct file *file) > if (!watchdog_active(wdd)) > err = 0; > else if (test_and_clear_bit(_WDOG_ALLOW_RELEASE, &wd_data->status) || > - !(wdd->info->options & WDIOF_MAGICCLOSE)) > + !(wdd->info->options & WDIOF_MAGICCLOSE)) { > err = watchdog_stop(wdd); > > - /* If the watchdog was not stopped, send a keepalive ping */ > - if (err < 0) { > - pr_crit("watchdog%d: watchdog did not stop!\n", wdd->id); > - watchdog_ping(wdd); > + /* If the watchdog was not stopped, send a keepalive ping */ > + if (err < 0) { > + pr_crit("watchdog%d: watchdog did not stop!\n", wdd->id); > + watchdog_ping(wdd); > + } > } > + else > + pr_info("watchdog%d: closing while running!\n", wdd->id); > > watchdog_update_worker(wdd); And I am able to reliably have it show "closing while running" (I ran the test several times, as the original issue was reproducible _most_ of the time but not always for some reason) root@rawhide:~# grep -e watchdog: -e 'Linux version' /var/log/messages Aug 5 15:31:46 rawhide kernel: watchdog: watchdog0: watchdog did not stop! Aug 5 15:31:55 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 15:33:02 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 15:35:54 rawhide kernel: watchdog: watchdog0: closing while running! Aug 5 15:36:02 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 15:38:30 rawhide kernel: watchdog: watchdog0: closing while running! Aug 5 15:38:38 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 15:42:30 rawhide kernel: watchdog: watchdog0: closing while running! Aug 5 15:42:38 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 15:43:16 rawhide kernel: watchdog: watchdog0: closing while running! Aug 5 15:43:24 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 15:54:39 rawhide kernel: watchdog: watchdog0: closing while running! Aug 5 15:54:47 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 15:57:29 rawhide kernel: watchdog: watchdog0: closing while running! Aug 5 15:57:37 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 16:02:59 rawhide kernel: watchdog: watchdog0: closing while running! Aug 5 16:03:07 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 16:04:24 rawhide kernel: watchdog: watchdog0: closing while running! Aug 5 16:04:32 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 Aug 5 16:07:26 rawhide kernel: watchdog: watchdog0: closing while running! Aug 5 16:07:35 rawhide kernel: Linux version 7.2.0-rc6+ (XXXXXXXXXXXXXX) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld version 2.46.1-1.fc44) #27.fc44 SMP PREEMPT_DYNAMIC Wed Aug 5 15:13:04 MDT 2026 That being said "watchdog did not stop!" and "closing while running!" both sound like something "bad" happened. In this case, it isn't because systemd wants it like that. However, it could be bad with a misbehaving userspace application. The patch is ready to go but I will probably reach out to one of the maintainers for input. Setting needinfo on myself while I do so.
> That being said "watchdog did not stop!" and "closing while running!" both sound like something "bad" happened. In this case, it isn't because systemd wants it like that. However, it could be bad with a misbehaving userspace application. The patch is ready to go but I will probably reach out to one of the maintainers for input. Setting needinfo on myself while I do so. Yeah, the kernel has insufficient info to know if it is defintely a flaw in userspace apps or not. That's why I think the "EBUSY" case should be "pr_info" to indicate something perhaps unusual, as opposed to a definite serious failure which pr_crit suggests - not that you can see a presentation difference in dmesg from those but at least message log level filtering can hide the pr_info IIUC.
I didn't hear back from the maintainer, so I went ahead and just submitted the patch as is. https://lore.kernel.org/all/20260824205051.4117285-2-chaithco@redhat.com/ I don't expect this to be accepted as is, and can use that conversation to figure out a better approach if one exists. Leaving needinfo on myself for that conversation.
Quick update; a maintainer recommended instead just adding an additional log line if the close() function returns an error. However, in further thinking on this, systemd is the only entity I know of which deliberately closes but doesn't disarm the watchdog. Afaik, even cluster suites that leverage watchdog does so with the intended use case (open it, try to ping it regularly, if you can't then the system resets). It may be best to more simply open a PR with systemd to at least warn or something of that happening to help explain why the kernel ring buffer has that pr_crit log line.
I also went ahead and opened a PR against systemd; https://github.com/systemd/systemd/pull/43552 as the issue here is the intent is unclear but intent resides in the entity closing the watchdog. This PR attempts to do just that. On the kernel change, I heard back from the maintainer and their response is echoing the sentiment that determining intent from the kernel is a challenge. Thus systemd PR.