We need to retry to opening of the watchdog, because the device becomes available asynchronously. The watchdog is opened in two places: - in pid1 in the main loop. The loop has a ratelimit, but during a boot we iterate in it fairly quickly. On my test VM with 'iTCO_wdt', version 2: $ journalctl -b --grep 'Failed to open any watchdog'|wc -l 3398 After the device has been processed by udev, it is initialized successfully. - in shutdown. In that case, we most likely don't need to try more than once, because we mostly care about the case where the watchdog device was present and configured previously. But in principle it is possible that we might attempt shutdown while the machine was initializing, so we don't want to disable retries. Nevertheless, watchdog_ping() is called from a loop that might be fairly tight, so we could end up trying to reopen the device fairly often. This probably doesn't matter *too* much, but it's still ugly to try to open the device without any ratelimit. Usually the watchdog timeout would be set to something like 30 s or a few minutes. OTOH, on my VM, the device becomes avaiable at 4.35 s after boot. So let's use 5 s as a value that is small enough to be much smaller than any normal watchdog timeout, but large enough that we can expect to do no more than a 1-2 retries during a normal boot.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack