>After a bit of testing with Restart-Computer and shutdown /r /f, I've found that no officially-documented shutdown command or function comes close in speed -- they both take a fair bit of time to work, and importantly, they both register in the Event Log as a clean shutdown. So what's going on here?
IME shutdown -r now definitely takes it sweet time (ie. getting stuck on "A stop job is running ..."
> (ie. getting stuck on "A stop job is running ..."
Trying to unmount a manually mounted network drive after already taking down the network... very frustrating. Seeing the time remaining counter jump from 30 seconds to 2+ minutes after the first 30 seconds passes is rage inducing. Do I really need to read the jargon dense documentation for a damn init system to get my computer to behave in a sensible way? Thanks Lennart.
-f / --force : "Force immediate halt, power-off, or reboot. When specified once, this results in an immediate but clean shutdown by the system manager. When specified twice, this results in an immediate shutdown without contacting the system manager."
"...all processes will be killed forcibly and all file systems are unmounted or remounted read-only. This is hence a drastic but relatively safe option to request an immediate reboot. If --force is specified twice for these operations, they will be executed immediately without terminating any processes or unmounting any file systems. Warning: specifying --force twice with any of these operations might result in data loss."
Indeed the feature is undocumented, but it's been known for some time - its goal is to mimic as much as possible the reset button, for those situations when your computer freezes up to a point where Ctrl+Alt+Del works, but literally no other process responds. Think "Background process locked up my OS, and I can't do anything short of unplugging the computer." Especially helpful on a laptop where the physical reset button is not available.
I can name hundreds of occasions from first-hand experience where it hasn't worked in the past 26 years for me on a variety of machines in various environments.
One prominent example I've seen multiple times, is hanging in the shutdown screen where no text appears under the spinning dots, and Ctrl-Alt-Del does nothing.
Ctrl+Alt+Del invokes WinLogon, the highest priority process, that then delivers the task manager. I believe this is a kernel invocation, so regardless of user land dysfunction, it will always work. Tthis is possibly attributable as much to convenience as it is to security -- the Secure Attention Sequence[1] is intended as a login-spoofind protection which will suspend other tasks (like a spoofed login screen) before continuing forward with user auth.
> I believe this is a kernel invocation, so regardless of user land dysfunction, it will always work.
It may always work from the kernel's standpoint, but this doesn't necessarily make it usable.
Anything that blocks the display of WinLogon (e.g., the GPU has crashed and is unresponsive) would render this emergency restart mechanism unusable, and typically, situations like this are usually the only time I would need such a feature.
A group policy can be enabled on most variants of Windows (dating back to around NT 4 or Windows 2000, I think) to start with a dialog saying "Press Ctrl-Alt-Delete to begin", and pretty much nothing else, exactly for the reasons you describe.
Though Microsoft's current security recommendation is against setting that policy for accessibility reasons. [0]
Windows since 8 has worked on hardening/strengthening the "Secure Desktop" that login flows (and UAC prompts) happen on so that as much as possible malware shouldn't be able to run in those sandboxes.
I feel like it worked more reliably in XP and below, ever since vista I’ve had less success.
With that said, system stability as a whole seems to have improved dramatically since those days, I don’t need to reach for it very often.
I had a situation a month ago where my computer froze up (it was a couple months old at the time) and literally nothing would respond, even control-alt-delete, but my mouse cursor would still move around. I have no idea what caused that (it was a fresh restart after installing a GPU driver) but whatever drives the cursor display must be even higher priority than C-A-Del.
Most graphics cards implement a hardware mouse cursor where the video card reads the current pointer location from memory and overlays the cursor on the screen. So I guess if the driver for the mouse and the video driver are both still running (the kernel hasn’t stopped completely) that will still work even if Winlogin is screwed to the point where it can’t show the CTRL-ALT-DEL screen.
Happy to be corrected by someone who knows more about the windows kernel. :)
Interesting I didn’t know that. Some part of the kernel was fucked for sure as even the hardware sleep button in my keyboard didn’t work but I guess if the display driver was functioning that would be all that was needed.
They may be disabled by distros to enhance security against physical access attacks.
It can also be challenging to actually input a magic-sysrq combo on many modern keyboards where sysrq isn't its own key, if it's labeled at all as some Fn-key contortion.
Personally I value being able to trigger oomkiller early when a process is eating up RAM, and being able to SIGKILL kwin_x11 on Nvidia or whatever other process is wedging Linux shutdown, instead of waiting multiple minutes for systemd to give up waiting and SIGKILL it directly. In terms of physical access attacks, it's just as viable and far more powerful to add a keylogger to my keyboard or Linux distro, or pull and image my hard drive, than to gasp kill processes or sync filesystem data to disk, oh the horror!
WRT the physical security argument in favor of disabling sysrq, my assumption is it's more aimed towards defeating quick-n-dirty mischief style abuse.
Ages ago I worked with a small team of young sysadmins who would often cause trouble for one another abusing things like sysrq, or poorly configured XFree86 instances without DontZap enabled (ctrl-alt-backspace termination, to a shell when startx/xinit is being used). Most of the time nothing malicious was actually done. But when you return to your screen-locked X desktop to find a fullscreen VC with a root shell blinking back at you and an empty history, guess what you'll at least have on the back of your mind for the rest of the workday?
From what I recall it needs to be enabled (or not be disabled) when the kernel is compiled and in some cases a flag must be put on the kernel command line while booting.
They aren't exactly the same thing, I suppose, but there's enough functional overlap that if you already have one, it's hard to justify adding another. You don't want too many of these "escape sequences", because every kernel-side keyboard interrupt becomes a thing that:
* Userland doesn't get to use that keyboard shortcut any more.
* Someone might accidentally trigger, and if they don't know what's going on, they become stuck.
* It's another thing that anyone building a captive kiosk has to know how to disable.
> Especially helpful on a laptop where the physical reset button is not available.
Are there any where holding the power button for 10-15 seconds doesn't work? This has always been a reliable technique for me, when using linux on numerous different laptops from different manufacturers.
Besides the mentioned NtSetSystemPowerState function, which this feature calls, there are also other undocumented API functions that allow to shutdown / restart the sytem immediately, like NtRaiseHardError (which allows to cause a bluescreen-like unclean shutdown with normal user permissions as a fun side-effect).
49 comments
[ 2.9 ms ] story [ 125 ms ] thread>After a bit of testing with Restart-Computer and shutdown /r /f, I've found that no officially-documented shutdown command or function comes close in speed -- they both take a fair bit of time to work, and importantly, they both register in the Event Log as a clean shutdown. So what's going on here?
IME shutdown -r now definitely takes it sweet time (ie. getting stuck on "A stop job is running ..."
Trying to unmount a manually mounted network drive after already taking down the network... very frustrating. Seeing the time remaining counter jump from 30 seconds to 2+ minutes after the first 30 seconds passes is rage inducing. Do I really need to read the jargon dense documentation for a damn init system to get my computer to behave in a sensible way? Thanks Lennart.
https://man.openbsd.org/halt
https://manpages.debian.org/halt
-f / --force : "Force immediate halt, power-off, or reboot. When specified once, this results in an immediate but clean shutdown by the system manager. When specified twice, this results in an immediate shutdown without contacting the system manager."
"...all processes will be killed forcibly and all file systems are unmounted or remounted read-only. This is hence a drastic but relatively safe option to request an immediate reboot. If --force is specified twice for these operations, they will be executed immediately without terminating any processes or unmounting any file systems. Warning: specifying --force twice with any of these operations might result in data loss."
https://www.kernel.org/doc/html/latest/admin-guide/sysrq.htm...
echo 1 > /proc/sys/kernel/sysrq # enable sysrq
echo o > /proc/sysrq-trigger # immediately power off
I wonder what the history behind this feature is.
https://www.codeproject.com/Articles/34194/Performing-emerge...
[1]: https://en.wikipedia.org/wiki/Secure_attention_key
It may always work from the kernel's standpoint, but this doesn't necessarily make it usable.
Anything that blocks the display of WinLogon (e.g., the GPU has crashed and is unresponsive) would render this emergency restart mechanism unusable, and typically, situations like this are usually the only time I would need such a feature.
Windows since 8 has worked on hardening/strengthening the "Secure Desktop" that login flows (and UAC prompts) happen on so that as much as possible malware shouldn't be able to run in those sandboxes.
[0] https://docs.microsoft.com/en-us/windows/security/threat-pro...
Happy to be corrected by someone who knows more about the windows kernel. :)
It'd let you safely shutdown when the computer is locked up otherwise.
It can also be challenging to actually input a magic-sysrq combo on many modern keyboards where sysrq isn't its own key, if it's labeled at all as some Fn-key contortion.
Ages ago I worked with a small team of young sysadmins who would often cause trouble for one another abusing things like sysrq, or poorly configured XFree86 instances without DontZap enabled (ctrl-alt-backspace termination, to a shell when startx/xinit is being used). Most of the time nothing malicious was actually done. But when you return to your screen-locked X desktop to find a fullscreen VC with a root shell blinking back at you and an empty history, guess what you'll at least have on the back of your mind for the rest of the workday?
They aren't exactly the same thing, I suppose, but there's enough functional overlap that if you already have one, it's hard to justify adding another. You don't want too many of these "escape sequences", because every kernel-side keyboard interrupt becomes a thing that:
* Userland doesn't get to use that keyboard shortcut any more.
* Someone might accidentally trigger, and if they don't know what's going on, they become stuck.
* It's another thing that anyone building a captive kiosk has to know how to disable.
Are there any where holding the power button for 10-15 seconds doesn't work? This has always been a reliable technique for me, when using linux on numerous different laptops from different manufacturers.
Win9x "tried" to intercept it; but was never 100% successful.