Date: Wed, 19 Oct 2016 14:20:46 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-arch@FreeBSD.org Subject: Re: watchdog end-user interface Message-ID: <a9f6f789-e2a8-1c66-18c0-acc8b6382950@FreeBSD.org> In-Reply-To: <21377.1476875898@critter.freebsd.dk> References: <ec3dfab5-c3bc-e9e5-181e-8c2704f60acd@FreeBSD.org> <21377.1476875898@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19/10/2016 14:18, Poul-Henning Kamp wrote: > -------- > In message <ec3dfab5-c3bc-e9e5-181e-8c2704f60acd@FreeBSD.org>, Andriy Gapon wri > tes: > >> I want to question if those options really belong to watchdogd. >> When a watchdog timer expires that results in a system-wide action (like a >> system reset). To me, that implies that there should be a single system-wide >> configuration point. And I am not sure that the daemon is the best choice for it. > > The reason I originally put it in a daemon, was to have the watchdog > implicitly test the kernels ability to schedule trivial processes. > > It used to be, and may still be so that, there are deadlocks where > the kernel was twiddling its thumbs but userland did not progress. > Typical triggers for this are disk-I/O errors, corrupt filesystems, > memory overcommit etc. > > A kernel-only watchdog patter would not trigger in that case. I addressed this further down my post. Just in case, I think that watchdogd should do the pat-pats as it does now. But that's different from setting the timeout. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a9f6f789-e2a8-1c66-18c0-acc8b6382950>