On Jan 17, 2008 11:16 AM, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > [Olaf van der Spek] > > I read the rationale, but in the ideal case you'd do that IO and > > sendsigs in parallel. > > I do not see that as an ideal. It would defeat the purpose of the
But you do agree the sync could introduce a delay? > sync call. The daemons killed by sendsigs should not have much IO to > push to the disk in the first place, because if they did, the safe > option would be for them to have their own stop script that make sure > the daemon is safely stopped before continuing. > > > I assume sync doesn't return until all IO is done. > > I assume so to. > > > Can't you move that sync to for example 5 seconds after TERM has > > been send? > > The purpose of the sync is to make sure all those daemons that do not > need to save state, and thus can be safely killed by sendsigs, get a > fair chance of terminating cleanly before they are forcefully killed. > Moving the sync after the TERM signal should not meet this goal. In that case you could increase the 10 seconds to 15 and do the sync at 5 seconds. That way, those daemons do still get 10 seconds after sync to cleanly terminate, but you do get the advantage of disk IO and terminating daemons in parallel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]