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.
> 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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"