From owner-freebsd-virtualization@FreeBSD.ORG Mon May 25 07:15:47 2015 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CE8048D; Mon, 25 May 2015 07:15:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CD9217F5; Mon, 25 May 2015 07:15:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from jre-mbp.elischer.org (ppp121-45-225-35.lns20.per1.internode.on.net [121.45.225.35]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t4P7FfY3060158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 May 2015 00:15:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5562CC17.70004@freebsd.org> Date: Mon, 25 May 2015 15:15:35 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Allan Jude , freebsd-virtualization@freebsd.org Subject: Re: can we get some interaction between halt/reboot and bhyve? References: <5562755C.8090407@redbarn.org> <20150525030835.GB37063@funkthat.com> <5562A5D0.7050207@redbarn.org> <5562BACA.4040104@freebsd.org> In-Reply-To: <5562BACA.4040104@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 07:15:47 -0000 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