Hi, On Thu, Sep 25, 2008 at 12:11:41PM -0500, kevin brintnall wrote: > On Thu, Sep 25, 2008 at 06:25:44PM +0200, Sebastian Harl wrote: > > > > RRDs out to disk.. When the daemon starts back up it can re-create its > > > > memory state with the journal. > > > > I don't think this is a good idea. When shutting down the daemon, I'd > > expect it to finish it's job - e.g. I might not want to restart the > > daemon, so I would lose data in that case. I agree that this is probably > > a very uncommon case but I'm sure there are quite a few other examples > > and I don't want to risk data loss even in very uncommon situations. > > I think it makes more sense to focus on how quickly the daemon can return > to service with no data loss. If we need to reboot for some reason, and > the daemon is blocking shutdown for 20 minutes, that's a problem.
I see and agree that this might be a problem. However, I still think that the _default_ behavior should follow the principle of least surprise and imho this includes writing all data to the RRD files. Providing an _optional_ way to only flush the journal sounds perfectly fine to me. If that was your original intention then sorry for the noise. > > > > What do you think about an expedited shutdown if we are journaling > > > > updates? We could simply flush the journal and exit. > > > > > > this would make sense to me ... maybe have different behaviour > > > depending on the signal it gets ? > > > > That won't work in this case. You cannot catch SIGKILL. > > We could catch SIGTERM for expedited shutdown and SIGINT for full-flush > shutdown? Then, each operator can decide which makes the most sense. Sounds good to me. Cheers, Sebastian -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
signature.asc
Description: Digital signature
_______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
