Hi David,
> If the watchdog timeout is below 2s, we end up with a timeout of 0s as
> glib event source. This causes unbound watchdog notifications. Avoid this
> by never using event-timeouts below 1s.
>
> Reported by Michael Biebl.
>
> ---
> src/main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/main.c b/src/main.c
> index e6bac6e..da0bd12 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -596,9 +596,10 @@ int main(int argc, char *argv[])
>
> seconds = atoi(watchdog_usec) / (1000 * 1000);
> info("Watchdog timeout is %d seconds", seconds);
> + seconds = (seconds < 4) ? 1 : seconds / 2;
>
> watchdog = g_timeout_add_seconds_full(G_PRIORITY_HIGH,
> - seconds / 2,
> + seconds,
> watchdog_callback,
> NULL, NULL);
while setting WatchdogSec=1 is pretty insane interval anyway, this now also means that setting it that low will cause a race condition between systemd's watchdog killing us and we are able to be quickly enough to respond with a keep alive message.
I get the feeling that if > 2s, then we should use g_timeout_add_seconds to get the advantage of being woken up with all other timeouts in our daemon. And when it is <= 2s, then we better use a high precision g_timeout_add.
One alternative is to actually use timerfd natively here and use kernel based range timers.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
