Date: Wed, 23 Sep 2015 23:01:03 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Colin Percival <cperciva@freebsd.org> Cc: Anthony Jenkins <Scoobi_doo@yahoo.com>, Jung-uk Kim <jkim@freebsd.org>, "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: Re: disabling sleep when shutting down Message-ID: <20150923221134.C29510@sola.nimnet.asn.au> In-Reply-To: <560110B3.6050401@freebsd.org> References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <20150920194946.U29510@sola.nimnet.asn.au> <560110B3.6050401@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Sep 2015 01:28:27 -0100, Colin Percival wrote: > On 09/20/15 03:04, Ian Smith wrote: > > On Sun, 20 Sep 2015 00:16:36 -0700, Colin Percival wrote: > > > On 09/18/15 11:29, Anthony Jenkins wrote: > > > > Is it possible for /etc/rc.shutdown to complete, but shutdown not > > > > occur? If so, there should be a mechanism to restore the ability to > > > > suspend. Other than that, I like it. > > > > > > Hmm... well, rc.shutdown runs before the system drops into single-user > > > mode. Which makes me think that maybe we should be making the kernel > > > call from inside init instead of from rc.shutdown. > > > > I still think disabling suspend from shutdown.c, at the same time as > > creating /var/run/nologin might be the best way to go, to avoid any > > possibility of untimely suspending once committed to shutting down. > > So you think we should disable suspend for the last 5 minutes before a > scheduled shutdown? This seems a bit strange to me... and I honestly can't > imagine a situation where you'd need to announce an imminent shutdown of > your laptop to logged-in users. Not necessarily 5 minutes, but maybe some time. I've long used several laptops as servers, one with websites, DNS, mail, etc, and with login users .. but I've not considered suspending on such (rare) shutdowns, nor there used scheduled shutdowns. It's hard sometimes imagining other peoples' experiences if they're very different from your own :) > > For one thing, shutdown's -o flag bypasses using init and calls halt or > > reboot directly, though I don't know if anyone uses that. > > Right, I figured it wasn't worth worrying about that case since anyone who > uses that hopefully knows what they're doing; also since that skips running > rc.shutdown there's a much smaller race window. Fair enough. > On the other hand, "send a signal to init" and the sysv compatible approach > of running `init [runlevel]` are likely to be used by other tools (e.g., > desktop environments), so I don't think we should assume that reboot/poweroff > requests always go through shutdown(8). That's a good point, and I do think the approach you're developing is looking pretty good overall .. except for one point, below. And I agree with your latest point, that shutdown to SU shouldn't disable suspend. > > For another, > > if shutdown fails for any reason, or is cancelled by signal by the user > > .. or in any case, I gather .. finish() removes /var/run/nologin, and > > could also there reenable suspend, covering Anthony's point. I's almost suggested /var/run/nosuspend, possibly holding the previous value of hw.acpi.lid_switch_state, when considering just the LID issue, but that would require removing on startup. > This would also be accomplished by having the suspend-disabling done by init; > if you tell shutdown(8) to not shut the system down, then it never sends the > relevant signal to init. The shutdown(8) utility doesn't do any shutting > down itself; it's just a front-end which makes an announcement, sets a timer, > and disables logins, and then ultimately asks init(8) to do the real work > (including spawning rc.shutdown). Indeed, not to mention the handy logging. However to come back to your initial issue: if you initiate a shutdown - I'd assumed you meant using 'shutdown -p now' ono? - hit return and snap the lid shut - let's say with practice and some bruised fingers in 0.3s - then are we sure that shutdown will progress to init, or from init to rc.shutdown in the other scenario jkim offered, within say 0.3s? IOW, are we sure a fix in init, or ever so shightly later in rc.shutdown, will always win that race, on a system that might be in a high load state? If not, the lid switch race becomes almost a separate issue, which the bother of adding setting hw.acpi.lid_switch_state would deal with, while needing storage to restore it on a cancelled or failed shutdown. Don't mind me, I've only used slower low-end gear for years now, and my concepts of how long things might take is conditioned on that. On one laptop I can't trust shutdown to wind down KDE including a browser with maybe 15 tabs inside two minutes, so always shut KDE down first .. this sort of stuff most people nowadays don't need to even consider. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150923221134.C29510>