== Delays on bad passwords considered harmful, accidental reboot edition

Here is what I just did to myself, in transcript form:

.pn prewrap on

>  $ /bin/su
>  Password: <type>
>  [delay...]
>  ['oh, I must have mistyped the password']
>  [up-arrow CR to repeat the su]
>  bash# reboot <CR>

Cue [[my 'oh damn' reaction
https://twitter.com/thatcks/status/536981119598882816]].

The normal root shell is bash and it had a bash history file with
'reboot' as the most recent command. When my _su_ invocation didn't drop
me into a root shell immediately I assumed that I'd fumbled the password
and it was forcing a retry delay (as almost all systems are configured
to do).  These retry delays have trained me so that practically any time
_su_ stalls on a normal machine I just repeat the _su_; in a regular
shell session this is through my shell's interactive history mechanism
with an up-arrow and a CR, which I can type ahead before the shell
prompt reappears (and so I do).

Except this time around _su_ had succeeded and either the machine or the
network path to it was slow enough that it had just looked like it had
failed, so my 'up-arrow CR' sequence was handled by the just started
root _bash_ and was interpreted as 'pull the last command out of history
and repeat it'. That last command happened to be a 'reboot', because I'd
done that to the machine relatively recently.

(The irony here is that [[following my own advice
../linux/NoMorePasswdAuthDelays]] I'd turned the delay off on this
machine. But we have so many others with the delay on that I've
gotten thoroughly trained in what to do on a delay.)