From: Rusty Russell <rusty@rustcorp.com.au>
To: ElementsProject/lightning
<reply+000bd6a4204707fe3cff5af6f0ab2717de4a0159d6b7127292cf00000001142959cb92a169ce0b0fb9db@reply.github.com>,
ElementsProject/lightning <lightning@noreply.github.com>
Cc: ccan@lists.ozlabs.org
Subject: Re: [ElementsProject/lightning] lightningd can crash if time moves backwards (#58)
Date: Mon, 31 Oct 2016 08:49:19 +1030 [thread overview]
Message-ID: <8737jd32fs.fsf@rustcorp.com.au> (raw)
In-Reply-To: <ElementsProject/lightning/issues/58@github.com>
gwillen <notifications@github.com> writes:
> In the ccan timer module, there's an assertion that can crash if time moves backwards. I know there are different perspectives on this, but it seems like lightningd can probably recover from slight non-monotonicity of time, so it's worth thinking about whether crashing is the best outcome in this case.
Ouch, thanks!
So you know what happened? NTP jump or manual setting?
> lightningd: ccan/ccan/timer/timer.c:307: timers_expire: Assertion `now >= timers->base' failed.
> lightningd(24325): FATAL SIGNAL 6 RECEIVED
> Fatal signal 6. Log dumped in crash.log
> Aborted
Yuck. Saying that time shouldn't go backwards is fairly fundamental,
and a useful sanity check. Lots of things assume time makes progress.
And a library can't report soft errors.
OTOH, real life always wins over my personal preferences :)
One option is to switch to timemono, which really can't go backwards.
But timemono is completely detached from any wallclock time, so it's
only useful for relative timers.
Which implies an API change to always use relative time (this actually
matches with all non-test usage I can find).
I'll look harder.
Thanks!
Rusty.
_______________________________________________
ccan mailing list
ccan@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/ccan
parent reply other threads:[~2016-10-30 22:19 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <ElementsProject/lightning/issues/58@github.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8737jd32fs.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=ccan@lists.ozlabs.org \
--cc=lightning@noreply.github.com \
--cc=reply+000bd6a4204707fe3cff5af6f0ab2717de4a0159d6b7127292cf00000001142959cb92a169ce0b0fb9db@reply.github.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox