Date: Mon, 25 May 2015 15:15:35 +0800 From: Julian Elischer <julian@freebsd.org> To: Allan Jude <allanjude@freebsd.org>, freebsd-virtualization@freebsd.org Subject: Re: can we get some interaction between halt/reboot and bhyve? Message-ID: <5562CC17.70004@freebsd.org> In-Reply-To: <5562BACA.4040104@freebsd.org> References: <5562755C.8090407@redbarn.org> <20150525030835.GB37063@funkthat.com> <5562A5D0.7050207@redbarn.org> <5562BACA.4040104@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/25/15 2:01 PM, Allan Jude wrote:
> On 2015-05-25 00:32, Paul Vixie wrote:
>>
>> John-Mark Gurney wrote:
>>> Shouldn't shutdown be used instead of reboot/halt? This allows
>>> various rc.d scripts to run, and you can use that to make sure all
>>> your bhyve instances are shutdown...
>> yes. but, if the reboot or poweroff or halt command is used, i'd like my
>> bhyve's to have enough time to umount their ufs zvol's. the rc.d script
>> should pass along some softer signal that can cause the bhyve to do its
>> own clean shutdown. but where SIGTERM is used, which is passed on as
>> ACPI power-off, i'd like busy (that is, not hung, trying hard to shut
>> down cleanly) bhyve's to get more time. the current poweroff/halt/reboot
>> command only looks for evidence of paging as a reason to extend the time
>> between SIGTERM and SIGKILL. i'd like to give it some bhyve-relevant
>> additional reason to delay that SIGKILL.
>>
> One option might be a sysctl to control how much time processes are
> given between the SIGTERM and SIGKILL.
>
> Right now, it looks like, unless paging it detected, processes are only
> given 5 seconds, which is definitely not enough for bhyve and some other
> processes. A tunable gives people the option of how long they want to
> wait. On my laptop, I likely want to shutdown in a hurry, but on my
> virtualization server, I'm willing to wait a few minutes to keep the
> shutdown clean.
you only want more tme if the processes in quetion are likely to respond.
I'd suggest that we have a way for a process to set some sort of '
Yeah I got the signal, and I'd like some time to work on it" response.
Since the original is a signal there is no back channel but maybe we
can think of a suitable method.
sysctls, process flags, ... timers? Maybe a per-process timer.
You set it to a time by which you promise to be finished and the
kernel promises to shoot you in the head if you were lying.
Then the existence of the timer inhibits further signals and kicks.
the timer could have a maximum setting that is set by sysctl..
so effectively an example might be.
set max time to 45 seconds (or whatever)
kick (HUP/TERM) all processes
processes set their suicide timers to 20 secs and start shutting
down. (sets process flag)
after 5 seconds rekicks (-9) all processes without said timer running.
(process flag?)
waits for count of timers to go to 0 (a sysctl?.. decrements when
process exits or it fires.)
kill -9 all remaining processes..
wait 5 secs..
reboot
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5562CC17.70004>