First, the important tl;dr: Yes, sysrq will reboot even if the OS is stuck in (one or more) D-wait(s).
This means that you can avoid power cycling, which is otherwise the only way to get out of a D-wait, if you can send a "b" to /proc/sysrq-trigger.
As I've mentioned in other threads, I have one machine that for reasons unknown (and un-fixable) will, after between 1 and 6 days of uptime, have one or more processes (most notably "lxpanel") go into status "D". When this happens, lxpanel stops updating the time or responding to any mouse clicks in the panel (*). When this happens, rebooting is the only fix. The problem is that the usual "sudo reboot" doesn't work, because the OS is stuck waiting for the D-waits to resolve, which they never will.
(*) And, just to be clear, the point is that other. mission-critical, processes stop working as well, so the reboot is needed to get things back to normal. But the OS itself still runs - you can still login, run (most) programs, etc.
Anyway, I figured out today that the following sequence works well, and eliminates the need for a power cycle:
1) ssh in from somewhere else (this doesn't work quite so well if you try it on the desktop, as I did initially)
2) Become root (sudo bash)
3) killall5 (kill all the processes except for your shell). This gives any processes that can exit gracefully, the chance to do so.
4) Wait a bit, to make sure all is well
5) echo b > /proc/sysrq.trigger
6) Voila! It reboots, regardless of any D waits..
Some notes:
1) Interestingly, B doesn't work. Only "b" does. No big surprise, given that Linux is generally case-sensitive.
2) The next thing to do is to get "sysrqd" running, so that I can do it remotely, without having to ssh in. Although I suppose this ends up being "6 of one, half dozen of the other". I suppose there may be cases where you can't ssh in, but sysrq still works. Have yet to see this.
3) When I did killall5 with no args, it went ahead and killed everything. I didn't expect this, because the man page for killall5 says:
SYNOPSIS
killall5 -signalnumber [-o omitpid[,omitpid..]] [-o omitpid[,omit-pid..]..]
which implies that the signal number is required. I expected an error message telling me that fact. So, I'm wondering what the default signal number to send is. Usually, it is 15, which is probably the case here, but it does show that the doc is out of sync with the program.
The point of all this is that it is probably better to send signal 1 (HUP) than 15 (TERM).
(Although it probably doesn't matter much in real life)
4) Finally, to be clear, people may say that this is unsafe and shouldn't be recommended, but the point is that you are in a situation where you were about to pull the power cord anyway, so there really isn't anything left to lose.
This means that you can avoid power cycling, which is otherwise the only way to get out of a D-wait, if you can send a "b" to /proc/sysrq-trigger.
As I've mentioned in other threads, I have one machine that for reasons unknown (and un-fixable) will, after between 1 and 6 days of uptime, have one or more processes (most notably "lxpanel") go into status "D". When this happens, lxpanel stops updating the time or responding to any mouse clicks in the panel (*). When this happens, rebooting is the only fix. The problem is that the usual "sudo reboot" doesn't work, because the OS is stuck waiting for the D-waits to resolve, which they never will.
(*) And, just to be clear, the point is that other. mission-critical, processes stop working as well, so the reboot is needed to get things back to normal. But the OS itself still runs - you can still login, run (most) programs, etc.
Anyway, I figured out today that the following sequence works well, and eliminates the need for a power cycle:
1) ssh in from somewhere else (this doesn't work quite so well if you try it on the desktop, as I did initially)
2) Become root (sudo bash)
3) killall5 (kill all the processes except for your shell). This gives any processes that can exit gracefully, the chance to do so.
4) Wait a bit, to make sure all is well
5) echo b > /proc/sysrq.trigger
6) Voila! It reboots, regardless of any D waits..
Some notes:
1) Interestingly, B doesn't work. Only "b" does. No big surprise, given that Linux is generally case-sensitive.
2) The next thing to do is to get "sysrqd" running, so that I can do it remotely, without having to ssh in. Although I suppose this ends up being "6 of one, half dozen of the other". I suppose there may be cases where you can't ssh in, but sysrq still works. Have yet to see this.
3) When I did killall5 with no args, it went ahead and killed everything. I didn't expect this, because the man page for killall5 says:
SYNOPSIS
killall5 -signalnumber [-o omitpid[,omitpid..]] [-o omitpid[,omit-pid..]..]
which implies that the signal number is required. I expected an error message telling me that fact. So, I'm wondering what the default signal number to send is. Usually, it is 15, which is probably the case here, but it does show that the doc is out of sync with the program.
The point of all this is that it is probably better to send signal 1 (HUP) than 15 (TERM).
(Although it probably doesn't matter much in real life)
4) Finally, to be clear, people may say that this is unsafe and shouldn't be recommended, but the point is that you are in a situation where you were about to pull the power cord anyway, so there really isn't anything left to lose.
Statistics: Posted by BigRedMailbox — Sun Jan 11, 2026 4:12 pm